sync: auto-sync from GURU-5070 at 2026-06-03 11:52:45

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-03 11:52:45

clients/glaztech/reports/2026-06-03-pci-cardholder-data-finding.md

@@ -0,0 +1,89 @@
+# Glaz-Tech Industries — Cardholder Data Storage Finding (PCI-DSS)
+
+**Classification:** CONFIDENTIAL — Security / PCI
+**Date:** 2026-06-03
+**Prepared by:** Arizona Computer Guru (Mike Swanson)
+**System:** Glaztech e-commerce/customer-portal web application (server `WWW`, 192.168.8.72) and its SQL Server backend (`192.168.8.62,3436`)
+**Method:** Read-only database inspection via GuruRMM. **No actual card numbers were retrieved.** All determinations were made by column **classification and aggregate counts** (length, all-digits vs. masked vs. encrypted patterns). No PAN, CVV, or cardholder value is reproduced in this report.
+
+---
+
+## Executive Summary
+
+The custom Glaztech web application stores **full credit card numbers (PAN) in plaintext** and **retains card security codes (CVV/CID)** in its SQL databases. This is a serious PCI-DSS compliance failure and a significant breach-liability exposure. Approximately **780 saved customer cards** (card-on-file) and **tens of thousands of historical payment records** are affected, with confirmed plaintext PANs and ~hundreds of stored CVV values.
+
+The Sage 100/MAS ERP database (`mas_gti`) is **not** the problem — it uses proper tokenization (`CreditCardGUID`, `Last4Unencrypted`, `EncryptedCreditCardNo`). **The exposure is entirely in the custom web application's own tables.**
+
+---
+
+## Findings
+
+### Finding 1 — Full PAN stored in plaintext (card-on-file) — HIGH/CRITICAL
+- **Table:** `dbo.cc_file` (`cc_number varchar(50)`, `cc_exp`, `cc_name`, `cc_code`, `activate`, …), present in every per-office database.
+- **Encryption:** none. Values classify as all-digits or digits-with-spaces/dashes (recoverable PAN). Zero rows contained alpha/base64 (encrypted) content.
+- **Scale (`cc_file` row counts by office DB):**
+
+| DB | rows | DB | rows |
+|---|---|---|---|
+| glaz_prod_elp | 179 | glaz_prod_alb | 44 |
+| glaz_prod_den | 190 | glaz_prod_slc | 41 |
+| glaz_prod_phx | 141 | glaz_prod_boi | 26 |
+| glaz_prod_brl | 88  | glaz_prod_shp | 14 |
+| glaz_prod (tuc) | 54 | glaz_prod_corp | 3 |
+| **Total** | | | **≈ 780 saved cards** |
+
+- Sample classification (`glaz_prod` / tuc, 54 rows): 29 plaintext PAN + 25 formatted PAN, **0 encrypted**, length 15–20.
+- **PCI-DSS Req 3.4:** PAN must be rendered unreadable anywhere it is stored. **Violated.**
+
+### Finding 2 — Stored CVV / card security codes — CRITICAL (indefensible)
+- **Column:** `dbo.cc_file.cc_code` (`varchar(20)`).
+- **Result:** populated with 3–4 digit values. In `glaz_prod` (tuc): **50 of 54 rows hold a stored CVV** (3–4 numeric digits). Other office DBs expected to mirror this.
+- **PCI-DSS Req 3.2:** sensitive authentication data (CVV/CVV2/CID) must **never** be stored after authorization — **no exception, even encrypted.** This is the most serious item and the fastest to remediate.
+
+### Finding 3 — Plaintext PAN in historical payment records — HIGH (large volume)
+- **Table:** `dbo.cof_payments_header` (`cc_number varchar(50)`), per-office.
+- **Scale / classification:**
+  - `glaz_prod_phx`: **14,496 rows — 11,794 full plaintext PANs**, ~2,700 masked/other.
+  - `glaz_prod` (tuc): 2,245 rows — 367 plaintext + 597 formatted + ~1,242 masked/other.
+- Represents years of transaction history retained with recoverable card numbers.
+
+### Finding 4 — Access controls / context
+- The web application connects with a **single shared SQL login (`tom`)** that has **full read on the card columns** (verified: `HAS_PERMS_BY_NAME` = 1 on `cc_number` and `cc_code`). No column-level protection or data masking.
+- Connection strings (with this login + password) are stored in the site `Web.config` on the web server.
+- The Sage 100 DB (`mas_gti`) uses tokenization and is materially compliant by comparison — scope of this finding is the **custom web app** only.
+
+---
+
+## Risk & Impact
+
+- **Breach exposure:** if the SQL server or web server is compromised, this is a reportable cardholder-data breach (full PAN + CVV in the clear).
+- **Compliance:** clear violations of PCI-DSS Req 3.2 (CVV retention) and Req 3.4 (PAN protection); likely invalidates the merchant's self-assessment and exposes Glaztech to card-brand fines and liability.
+- **CVV retention** specifically removes most "we were compliant" defenses in the event of a breach.
+
+---
+
+## Remediation Plan
+
+**Immediate (days):**
+1. **Stop writing `cc_code` (CVV)** in the application and **purge all stored CVV values** (`cc_file.cc_code`). This is the highest-priority, lowest-effort risk reduction and is indefensible to retain.
+2. Inventory and restrict who/what can read `cc_file` / `cof_payments_header`.
+
+**Short term (weeks):**
+3. Stop storing raw PAN. Move card-on-file to the **CyberSource token vault** (already in use for processing) — store a token reference instead of the PAN.
+4. Purge or strongly encrypt the historical `cc_number` columns in `cof_payments_header` and `cc_file` once tokenization is in place.
+
+**Hardening:**
+5. Least-privilege SQL accounts (separate read/write, no blanket card-column read), encryption at rest (TDE) as defense-in-depth, and secrets management for `Web.config` connection strings.
+6. Re-scope/refresh the merchant PCI SAQ after remediation.
+
+---
+
+## Evidence / Methodology (PAN-free)
+
+- Column discovery via `INFORMATION_SCHEMA.COLUMNS` (names matching card/cvv/expir/etc.).
+- Storage classification via aggregate `CASE`/`COUNT` only — e.g. `SUM(CASE WHEN col NOT LIKE '%[^0-9]%' AND LEN(col) BETWEEN 13 AND 19 THEN 1 ELSE 0 END)` to count full-PAN-shaped values without selecting them.
+- CVV detection via count of 3–4 digit `cc_code` values. No raw card data was selected, displayed, or stored at any point.
+
+---
+
+**Status:** Reported to ownership 2026-06-03. **No data was modified or deleted** — remediation pending client (Steve Eastman / Tom) direction. This finding should be raised with the client as a priority compliance/security item.

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

@@ -0,0 +1,154 @@
+# Glaz-Tech Industries — Website Security Assessment
+
+**Classification:** CONFIDENTIAL — Security
+**Date:** 2026-06-03
+**Assessor:** Arizona Computer Guru (Mike Swanson)
+**Target:** Glaztech customer/e-commerce web application — server `WWW` (192.168.8.72, public 65.113.52.88), site `glaztech_new` at `D:\web\glaztech_4`, SQL backend `192.168.8.62,3436`
+**Method:** Authorized read-only assessment via GuruRMM (config/registry inspection, source-code review of the on-server VB.NET source, and read-only/aggregate DB inspection). **No cardholder data and no passwords were retrieved** — sensitive columns were classified by aggregate only.
+
+> Companion report: `2026-06-03-pci-cardholder-data-finding.md` (cardholder-data storage detail).
+
+---
+
+## Overall Risk: CRITICAL
+
+The site stores cardholder data (PAN + CVV) and **all user passwords in plaintext**, contains SQL injection and reflected XSS, and runs on a server that doubles as a developer workstation with extensive remote-access and end-of-life software. Multiple findings are independently sufficient to cause a reportable breach.
+
+| # | Finding | Severity |
+|---|---|---|
+| C1 | Plaintext PAN + stored CVV in DB | Critical |
+| C2 | All user passwords stored in plaintext; passwords emailed in cleartext | Critical |
+| C3 | SQL injection via fake `quo()` escaper (incl. payment pages) | Critical |
+| C4 | Reflected XSS in `gt_errorpage.aspx` | High |
+| H1 | Production payment server is also a dev workstation (VS, SDKs, build tools) | High |
+| H2 | Remote-access sprawl incl. end-of-life RealVNC 4.2.8 + stale ScreenConnect v6 | High |
+| H3 | `debug="true"` + `customErrors=Off` + exceptions echoed to users | High |
+| H4 | Server accepts TLS 1.0/1.1 on the listener | High |
+| H5 | No cookie Secure/HttpOnly hardening, no MFA, no lockout, session-fixation risk | High |
+| H6 | Single shared SQL login with full card-column read; creds in `Web.config` | High |
+| M1 | Outdated/unused third-party components; SHA1 machineKey; source on prod | Medium |
+
+---
+
+## Critical Findings
+
+### C1 — Plaintext PAN and stored CVV (see companion PCI report)
+`cc_file` (~780 saved cards) and `cof_payments_header` (tens of thousands of rows; e.g. Phoenix 14,496 / 11,794 plaintext) store full card numbers unencrypted, and `cc_file.cc_code` retains CVV (PCI Req 3.2 — prohibited). Detail and remediation in the PCI report.
+
+### C2 — All passwords stored in plaintext; cleartext password email
+- **Customer portal:** auth stored proc `get_web_accesslevel` compares `web_security.web_password = @passwd` **with no hashing**. `web_security` holds **~9,000+ plaintext passwords** (corp 6,017 + tuc 3,012 + other offices), 0 hash-like values, lengths 3–19.
+- **Employees:** `emp/employee-login.aspx` "forgot password" verifies last name + email, then **emails the user their existing plaintext password** (`"The password to your employee profile is: " + pword`) — only possible with reversible/plaintext storage.
+- **Impact:** any DB read (or the existing SQLi) exposes every customer/employee credential in the clear; password reuse means broad downstream compromise. Weak "lastname + email" knowledge check gates the password email.
+- **Fix:** store only salted password hashes (PBKDF2/bcrypt/Argon2); never email passwords — implement a reset-token flow; force a global password reset after remediation.
+
+### C3 — SQL injection via non-escaping `quo()` helper
+```vb
+Function quo(stext) As String
+    Return "'" + stext + "'"     ' wraps in quotes but does NOT escape embedded quotes
+End Function
+```
+- Used to build **concatenated dynamic SQL** in multiple pages including payment flows (`ach.aspx.vb`, `quick-pay-ach.aspx.vb`, `quick-pay-pnc.aspx.vb`, `quick-pay.aspx.vb`, `order-detail*`). Any input containing `'` breaks out of the string → injection.
+- Codebase posture is *mixed*: 948 properly parameterized calls vs. **59 concatenated SQL statements** (~10 joining user input). The login path itself is parameterized (sproc) and **not** injectable; the risk is the concatenated set.
+- **Fix:** replace all concatenation with parameterized commands / stored procedures; delete `quo()`. Prioritize payment pages.
+
+### C4 — Reflected XSS in `gt_errorpage.aspx`
+- `smessage = Request.QueryString("errmsg")` (line 20) → `lblerr.Text = smessage` (line 48). `Label.Text` is **not** HTML-encoded, and the app redirects many exceptions to `gt_errorpage.aspx?errmsg=<msg>` (often containing raw `ex.Message`). An attacker-supplied `errmsg=<script>…</script>` executes in the victim's browser.
+- **Fix:** HTML-encode (`Server.HtmlEncode`) before output; stop placing exception text in URLs; show generic errors to users and log details server-side.
+
+---
+
+## Attack Path — A Single Guessed Login → the Entire Card Database
+
+Chaining the findings into the realistic worst case, with difficulty ratings.
+
+**Step 1 — Obtain a customer login (LOW).** Username = the customer **account number** (enumerable, not secret). Passwords are plaintext, **as short as 3 characters**, no complexity rules, and there is **no account lockout or rate-limiting** — unlimited guessing / credential-stuffing.
+
+**Step 2 — Normal UI (masked display).** Payment pages *display* cards masked to last-4 (`xxxx-xxxx-xxxx-1234`), so a point-and-click attacker sees last-4 + expiry + cardholder/billing data and can transact on saved cards. Note: the read proc `get_cc_data` is `SELECT * FROM cc_file WHERE acct_no=@acctno` — it returns the **full PAN and CVV to the application server**; only the *display* is masked, and the `@acctno` parameter makes it an IDOR-shaped full-card read. Any endpoint returning that proc's output unmasked (or the SQLi below) yields full numbers.
+
+**Step 3 — SQL injection (FULL exposure).** The post-login payment pages (`quick-pay`, `ach`, `quick-pay-pnc`) build SQL with the non-escaping `quo()` helper and require only a valid session. A logged-in attacker can UNION-inject `SELECT cc_number, cc_code FROM cc_file` and exfiltrate **every stored full card number AND CVV** for the office — directly, because the data is **plaintext** (no encryption/key to defeat). UI masking is irrelevant at this layer.
+
+| Goal | Difficulty |
+|---|---|
+| Obtain a valid login | **Low** (no lockout, guessable username, 3-char plaintext passwords) |
+| See last-4 / transact via UI | **Low** |
+| Exfiltrate ALL full PAN + CVV | **Low–Moderate** (one login + standard SQLi; plaintext data) |
+
+**There is no defense-in-depth** — every compensating control (lockout, password hashing, PAN encryption, parameterized queries) is absent, so the first failure is the last failure. Highest-leverage breakers: login lockout/rate-limiting, parameterize the payment-page SQL (remove `quo()`), purge CVV + tokenize/encrypt PAN.
+
+---
+
+## Why the Cards Are Stored, and Where They Flow
+
+**Business purpose — card-on-file invoice auto-pay.** Cards are stored (with an `activate` flag on `cc_file`) so the business can automatically charge customers' open invoices. The proc `i_get_cc_on_file_invoices` joins `invoice` × `cc_file` for active cards with an outstanding, delivered balance; `gt_auto_process_2020.dll` (in `bin`, with stale copies in `Old_bin`/`Old_code\Bin`) is the engine that reads the stored card and bills it via CyberSource. There is no scheduled task — the run is triggered from within the web app (most likely staff-initiated). The large `cof_payments_header` history (e.g. 14,496 rows in Phoenix) is years of these charges.
+
+**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`).
+
+**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.
+
+---
+
+## High Findings
+
+### H1 — Production payment server is also a developer workstation
+Installed on the live server: **Visual Studio Community 2015 and 2022, .NET 8 SDKs, MSBuild/Build Tools, TFS office integration, IIS 10 Express, Notepad++, WinRAR 7.22, OpenSSL 3.5.0**. Full application **source code is on the box** (128 `.vb` + 125 `.aspx.vb`, not precompiled). This massively expands attack surface and blast radius on the host that processes cardholder data. **Fix:** move development off the production host; deploy precompiled; remove SDKs/IDEs/dev tools.
+
+### H2 — Remote-access sprawl, including end-of-life software
+Present: **RealVNC Enterprise E4.2.8** (≈2009 — critically outdated, known auth-bypass-class issues), **ScreenConnect client v6.0.11622 (2018, stale)** alongside a current ScreenConnect, **Splashtop**, **Datto RMM + Datto EDR**, **Syncro**, plus GuruRMM. 6+ remote-management agents = large unmonitored access surface. **Fix:** remove RealVNC and the stale ScreenConnect immediately; rationalize to a single sanctioned remote-access tool; inventory who controls each.
+
+### H3 — Debug/error information disclosure
+`Web.config`: **`<compilation debug="true" …>`** in production and **`<customErrors mode="Off"/>`** present; login/employee code echo `ex.Message` to the page or via `errmsg`. Leaks stack traces, SQL errors, internal paths. **Fix:** `debug="false"`, `customErrors="On"` with a generic page, stop surfacing exception text to users.
+
+### H4 — Listener accepts TLS 1.0/1.1
+SChannel: **TLS 1.0 Server `Enabled=1`** (and TLS 1.1 at OS default = enabled); TLS 1.2 enabled. The public HTTPS endpoint therefore still negotiates deprecated TLS — a PCI listener finding. **Fix:** disable TLS 1.0/1.1 (SChannel server) after confirming no legacy client dependency; keep TLS 1.2.
+
+### H5 — Session/credential handling
+- Custom **Session-variable auth** (no ASP.NET Forms auth); **no session-ID regeneration on login** → session-fixation risk.
+- **No `requireSSL`** and **no `httpOnlyCookies`** configured → cookies not marked Secure (site was HTTP-reachable until the 2026-06-03 HTTP→HTTPS redirect was added).
+- **No MFA, no account lockout / rate limiting**; username = customer **account number** (guessable) → brute-force exposure.
+- **Fix:** Secure+HttpOnly cookies, regenerate session on login, add lockout/throttling, consider MFA for employee/admin access.
+
+### H6 — Database access model
+Web app connects with a **single shared SQL login (`tom`)** that has full read on card and password columns (no column-level control); **connection strings with credentials are in `Web.config`** on the web server (15+ per-office DBs). **Fix:** least-privilege per-function accounts, remove blanket card/password read, protect/secret-manage connection strings, enable TDE at rest.
+
+---
+
+## Medium / Component Hygiene
+
+- **Outdated third-party libraries in `bin`:** `AjaxControlToolkit 3.0.30930` (2008 — present but **not referenced**, remove it), `Microsoft.IdentityModel.Tokens` / `System.IdentityModel.Tokens.Jwt 5.1.2` (2017), `CyberSource SDK 1.4.10` (legacy), assorted GrapeCity ActiveReports versions. Inventory and update/remove.
+- **`machineKey validation="SHA1"`** — move to SHA-256 (AES/HMACSHA256) with managed keys.
+- **Source code resident on production** — remove; deploy build artifacts only.
+- **OpenSSL 3.5.0 / WinRAR 7.22 / Chrome** on a server — patch or remove; reduce footprint.
+
+---
+
+## 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.
+- TLS 1.2 to CyberSource now works (payment outage fixed 2026-06-03).
+
+---
+
+## Prioritized Remediation Roadmap
+
+**Now (days):**
+1. Purge stored CVV (`cc_file.cc_code`); stop writing it.
+2. `debug="false"`, `customErrors="On"`; HTML-encode `gt_errorpage` output; stop echoing exceptions.
+3. Remove RealVNC 4.2.8 and the stale ScreenConnect v6 client.
+4. Disable TLS 1.0/1.1 on the listener.
+
+**Short term (weeks):**
+5. Convert passwords to salted hashes; replace the email-the-password flow with reset tokens; force a global reset.
+6. Parameterize the concatenated SQL (payment pages first); delete `quo()`.
+7. Secure+HttpOnly cookies; session regeneration; login throttling/lockout.
+8. Move card-on-file to the CyberSource token vault; purge/encrypt historical PAN columns.
+
+**Structural (project):**
+9. Separate development from the production host; deploy precompiled; remove dev tooling and source from prod.
+10. Least-privilege DB accounts, secret management for connection strings, TDE; re-scope the merchant PCI SAQ after remediation.
+
+---
+
+**Status:** Assessment complete 2026-06-03. **No changes were made to the application, database, or data during this assessment** (read-only). Findings to be reviewed with the client (Steve Eastman / Tom) as priority security and PCI remediation. This report contains no card numbers or passwords.