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-04 07:07:43

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-04 07:07:43
This commit is contained in:
Mike Swanson
2026-06-04 07:07:48 -07:00
parent a22bc8ea06
commit 64b2d9e668
4 changed files with 137 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -149,7 +149,8 @@ SChannel: **TLS 1.0 Server `Enabled=1`** (and TLS 1.1 at OS default = enabled);
- 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.
- **Detection blind spot (see Appendix A):** the employee login returns **HTTP 200 on both success and failure** (no redirect-on-success), and the app logs **no failed login attempts** anywhere. App-level auth never touches the Windows Security log. The net effect is that a slow credential-guessing attack against staff or customer accounts would be **effectively invisible** — there is no lockout to stop it and no log to detect it after the fact.
- **Fix:** Secure+HttpOnly cookies, regenerate session on login, add lockout/throttling, **add failed-login logging (timestamp, username, source IP)**, 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.
@@ -193,4 +194,37 @@ Web app connects with a **single shared SQL login (`tom`)** that has full read o
---
**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.
## Appendix A — Intrusion / Brute-Force Log Review (2026-06-04)
**Question asked:** Is there evidence in the logs of anyone trying to brute-force the website logins (or the server)?
**Method (read-only, via GuruRMM):** 7 days of IIS request logs (`C:\inetpub\logs\LogFiles\W3SVC4`, ~52,000 requests, May 29 – Jun 4) plus the Windows Security event log (4625 failed logons / 4624 successful logons, 7-day window; log retains 65 days back to 2026-03-31). No data was modified.
**Bottom line: NO evidence of a brute-force attack — not against the website logins, and not against the Windows server.**
### Website logins (IIS)
Two login endpoints on the live site: `/customer_login.aspx` (customer portal) and `/emp/employee-login.aspx` (staff portal).
| Endpoint | Success | Fail | Reading |
|---|---|---|---|
| `/customer_login.aspx` | 2,547 (HTTP 302) | 78 (HTTP 200) | ~97% success — normal traffic across 740 distinct IPs, each logging in a few times/week |
| `/emp/employee-login.aspx` | 77 (302) | 381 (200) | **Artifact, not failures** — see below |
- **Important interpretation correction:** the employee login returns **HTTP 200 on BOTH success and failure** (it does not use the post-redirect-get/302 pattern the customer login uses). Status code alone therefore does **not** indicate a failed staff login. The apparent "381 failures" is a measurement artifact. Confirmed by pulling full request timelines: the top "suspect" IP `160.3.157.9` (24 hits, "0 successes" by the 302 metric) is a single legitimate employee on an iPhone (consistent iOS 18.7 Safari UA all week) who POSTs the login and then loads `/emp/check-hours2.aspx` + `/emp/index.aspx` with real content — i.e. a logged-in employee checking a timecard. Every "failure-heavy" employee IP fits the same benign shape (residential IP, single consistent device UA, reaches protected pages).
- **No brute-force / credential-stuffing signature** anywhere: no single IP firing rapid high-volume login POSTs, no username-cycling at machine speed, no scanner/bot user-agents hammering the login.
- **Minor observation (not an attack):** scattered bursts of **HTTP 500** on post-login pages (`invoices.aspx`, `quotes.aspx`, `place_orders.aspx`, `billing-statements.aspx`, `online-payment-pnc.aspx`) — several IPs firing 8–17 identical 500s within a single second (automated, not human clicking). Source IPs incl. `201.146.179.166`, `64.178.182.162`, `205.185.107.49`, `172.87.137.60`. These read more like a buggy page than a campaign (different pages, different residential IPs, normal browser UAs), **but** given C3 (the SQL-injectable `quo()` path), a 500 on a login/data page is exactly what a quote character in input produces against that code — worth an app-side look at what those pages throw. IIS does not log POST bodies, so the attempted inputs are not recoverable from these logs.
### Windows server (Security log)
- **13** failed logons (4625) in 7 days — trivial volume (an internet-exposed Windows host sees thousands/day).
- **All 13 were LogonType 3 (SMB/network), 100% from internal LAN IPs, zero from any public IP.** No RDP (type 10) failures at all.
- Targeted usernames: 12 blank (null/anonymous SMB) + 1 `tomabens` (internal — a stale cached credential or service, not an attack).
- **No successful remote logons from any external IP** (4624 type 3/8/10).
- **Inference:** the absence of *any* external 4625 strongly indicates RDP/SMB are **not internet-exposed** (a reachable RDP port produces a relentless type-10 failure stream within hours). The only meaningful internet-facing attack surface is the web application on 443 — which is exactly where the risk in this report lives.
### Takeaway for remediation
The review found no attacker, but it confirmed the **detection gap** noted in H5: 200-on-both responses + no lockout + no failed-login logging mean a slow guessing attack would be invisible here. **Add failed-login logging and account lockout** (already on the roadmap) — without them, "has anyone tried to break in?" cannot be answered with confidence going forward. Re-run this same log review periodically.
*Read-only review. No card numbers, passwords, or POST bodies were retrieved or are reproduced.*
---
**Status:** Assessment complete 2026-06-03; intrusion/brute-force log review added 2026-06-04 (Appendix A). **No changes were made to the application, database, or data** (read-only throughout). Findings to be reviewed with the client (Steve Eastman / Tom) as priority security and PCI remediation. This report contains no card numbers or passwords.

65
clients/glaztech/session-logs/2026-06-04-session.md Normal file
View File

@@ -0,0 +1,65 @@
# Glaztech — Session Log 2026-06-04
## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin
## Session Summary
Performed a read-only intrusion / brute-force log review on the Glaztech web server (`WWW`, agent `455a1bc7-1c29-42bc-b597-fa1e64f08eec`, Windows Server 2019, agent v0.6.54) via GuruRMM, following up on the 2026-06-03 website security assessment. Question: is there evidence anyone tried to brute-force the website logins or the server itself.
Analyzed 7 days of IIS logs (`C:\inetpub\logs\LogFiles\W3SVC4`, ~52,000 requests, May 29 – Jun 4). Identified the two login endpoints (`/customer_login.aspx`, `/emp/employee-login.aspx`), then broke POSTs down per source IP with HTTP status codes. An initial pass flagged the employee portal as suspicious (381 "failures"/HTTP 200 vs 77 "successes"/302 — an inverted ratio vs the customer login). Pulling full per-IP request timelines corrected this: the employee login returns **HTTP 200 on both success and failure** (no redirect-on-success), so status code alone does not indicate a failed staff login. The top "suspect" IP `160.3.157.9` proved to be a single legitimate employee on an iPhone checking timecards. No brute-force or credential-stuffing signature exists on either endpoint.
Also reviewed the Windows Security event log (4625 failed logons / 4624 successes, 7-day window): only 13 failed logons, all LogonType 3 (SMB) from internal LAN IPs, zero external, no RDP failures, and no successful remote logons from public IPs — indicating RDP/SMB are not internet-exposed and nothing got in at the OS auth layer.
Folded the findings into the security record: added **Appendix A — Intrusion / Brute-Force Log Review (2026-06-04)** to `clients/glaztech/reports/2026-06-03-website-security-assessment.md`, and extended finding **H5** with a detection-blind-spot note (200-on-both + no lockout + no failed-login logging = slow guessing would be invisible).
## Key Decisions
- **Used IIS request logs as the primary evidence source, not the Windows Security log**, because the app's custom session-based auth never generates Windows logon events. The Security log was used only to rule out RDP/SMB brute force against the host.
- **Did not treat HTTP 200 on the employee login as a failure** once the timelines showed 200-on-success. Reported the corrected interpretation rather than the alarming-but-wrong intermediate read.
- **Flagged the HTTP 500 bursts** as worth an app-side look (possible SQLi error path per C3) but explicitly classified them as not-a-brute-force, to avoid overstating the threat.
- **Recorded the detection gap as the actionable outcome** — the review found no attacker, but confirmed that a slow guessing attack would currently be undetectable; reinforces the existing #32378 remediation (add lockout + failed-login logging).
## Problems Encountered
- **`jq -n --arg` heredoc capture glitched** when dispatching the Security-log script (parse error / empty command). Resolved by writing the PowerShell to `.claude/tmp/seclog.ps1` and passing it with `jq --rawfile`, which is robust against embedded quoting.
- **IIS logs do not record POST bodies**, so attempted usernames/passwords are not recoverable — noted as a limitation; confirming which accounts (if any) were targeted would require app-level auth logging that does not exist.
## Configuration Changes
- Modified: `clients/glaztech/reports/2026-06-03-website-security-assessment.md` — added Appendix A (2026-06-04 log review); extended H5 with detection-blind-spot note + failed-login-logging fix; updated Status line.
- Created: `clients/glaztech/session-logs/2026-06-04-session.md` (this file).
- Local-only (gitignored): `.claude/current-mode` set to `infra`; transient `.claude/tmp/seclog.ps1`, `.claude/tmp/rmm.token`, `.claude/tmp/rmm.cmd`.
## Credentials & Secrets
- None discovered or created. RMM admin credential read from vault `infrastructure/gururmm-server.sops.yaml` (unchanged).
## Infrastructure & Servers
- **WWW** (Glaztech web server) — internal `192.168.8.72`, public `65.113.52.88`, Windows Server 2019 (build 17763), GuruRMM agent `455a1bc7-1c29-42bc-b597-fa1e64f08eec` (v0.6.54), client "Glaztech Industries" / site "TUS - Tucson".
- Active IIS site: `W3SVC4` (log dir `C:\inetpub\logs\LogFiles\W3SVC4`; daily `u_exYYMMDD.log`). Older sites W3SVC1/2/3 are stale (last writes 2018–2022).
- SQL backend (context only, not touched): `192.168.8.62,3436` (`GTI-INV-SQL`).
## Commands & Outputs
- IIS analysis dispatched as PowerShell via GuruRMM (`POST /api/agents/<id>/command`), parsing `#Fields`-keyed log lines for `cs-method`, `cs-uri-stem`, `c-ip`, `sc-status`, `date`, `time`, `cs(User-Agent)`.
- Key counts: customer login 2,547×302 / 78×200 / 5×500; employee login 77×302 / 381×200 / 6×500; 740 distinct IPs hit the login endpoints; 241 distinct IPs hit the employee login.
- Security log: span 2026-03-31 .. 2026-06-04; 4625 in last 7d = 13, all type 3, all internal, usernames = 12 blank + 1 `tomabens`; 4624 external type 3/8/10 = none.
## Pending / Incomplete Tasks
- **App-side investigation of the HTTP 500 bursts** on post-login pages (possible SQLi error path) — IPs `201.146.179.166`, `64.178.182.162`, `205.185.107.49`, `172.87.137.60`. Not yet handed to Tom.
- **#32378 (Waiting on Customer)** unchanged: add account lockout + failed-login logging (now explicitly tied to this review), fix SQLi, least-privilege the `tom`/`sysadmin` DB login, separate website DB from GTIware, stop storing cards / never CVV, encrypt at rest.
- Optional confirming check offered but not run: enumerate listening/forwarded ports on `WWW` to turn "RDP almost certainly not exposed" into "confirmed."
- Carried over: `corp` DB `cc_file` "Invalid object name" anomaly; confirm Payrilla payment-flow scope.
## Reference Information
- Report: `clients/glaztech/reports/2026-06-03-website-security-assessment.md` (Appendix A)
- Companion: `clients/glaztech/reports/2026-06-03-pci-cardholder-data-finding.md`
- Wiki: `wiki/clients/glaztech.md`
- Ticket: Syncro **#32378** (Glaztech website security — Waiting on Customer)
- RMM API: `http://172.16.3.30:3001` | agent id `455a1bc7-1c29-42bc-b597-fa1e64f08eec`