Security Export: Issues, Dependabot & CodeScan Alerts#154
Conversation
|
PR Summary: Add documentation for repository security findings: new issues/ directory with a README, detailed CodeQL code-scanning alerts, and Dependabot alerts (no code changes).
|
| @@ -0,0 +1,37 @@ | |||
| # Repository: LazyOwn | |||
|
|
|||
| **Description:** LazyOwn RedTeam/APT Framework is the first RedTeam Framework with an AI-powered C&C, featuring rootkits to conceal campaigns, undetectable malleable implants compatible with Windows/Linux/Mac OSX, and self-configuring backdoors. With its Web interface and powerful Console Client, it is the best combination for your Autonomous RedTeam/APT campaigns. | |||
There was a problem hiding this comment.
[CRITICAL_BUG] This README contains an explicit description of malicious capabilities (rootkits, backdoors, undetectable implants). Publishing such explicit capabilities in a public repository carries legal/ethical risks and may violate hosting policies. Remove or substantially redact these details from the public README and keep any security-research artifacts in a private, access-controlled location. If this snapshot must be public, rephrase to a high-level, non-actionable description and include a clear responsible-disclosure / safe-use statement.
# Repository: LazyOwn
**Description:** LazyOwn is a security testing and red-team automation framework that supports cross-platform agents and centralized orchestration. It is intended for authorized security assessments and research in controlled environments.
> Note: This project must only be used for lawful, authorized security testing. Do not use it for unauthorized access, disruption, or any activity that violates applicable laws or service terms.| ## Code Scanning Alerts | ||
| - [CodeScan #781](./codescan/alert_781.md) - py/incomplete-url-substring-sanitization (warning) - open | ||
| - [CodeScan #780](./codescan/alert_780.md) - py/incomplete-url-substring-sanitization (warning) - open | ||
| - [CodeScan #779](./codescan/alert_779.md) - py/incomplete-url-substring-sanitization (warning) - open | ||
| - [CodeScan #778](./codescan/alert_778.md) - py/incomplete-url-substring-sanitization (warning) - open | ||
| - [CodeScan #777](./codescan/alert_777.md) - py/incomplete-url-substring-sanitization (warning) - open | ||
| - [CodeScan #776](./codescan/alert_776.md) - py/overly-large-range (warning) - open | ||
| - [CodeScan #775](./codescan/alert_775.md) - py/overly-large-range (warning) - open | ||
| - [CodeScan #767](./codescan/alert_767.md) - py/bind-socket-all-network-interfaces (error) - open | ||
| - [CodeScan #766](./codescan/alert_766.md) - py/bind-socket-all-network-interfaces (error) - open | ||
| - [CodeScan #765](./codescan/alert_765.md) - py/bind-socket-all-network-interfaces (error) - open |
There was a problem hiding this comment.
[CRITICAL_BUG] This section enumerates active CodeQL/code-scanning alerts (including rule names). Publishing raw scanner findings and precise rule names publicly can facilitate abuse. Replace full alert dumps with a sanitized summary and remediation status (private link to details), or move detailed findings to a private security tracker. At minimum, avoid including concrete vulnerable code locations and exact rule text in public commits.
## Code Scanning Alerts (summary)
This snapshot includes open code scanning alerts from GitHub Advanced Security.
- Total open alerts: 10
- Tools: CodeQL
- Example categories:
- URL sanitization
- Network binding configuration
- Input range/validation
For full details (including file paths and rule identifiers), refer to the private security dashboard or your GitHub Security tab.| ### Patches | ||
| Version 4.13.2 addresses this issue as follows: | ||
|
|
||
| - The initial background thread (or async task( for heartbeat management is only launched if a client passes authentication in the `connect` handler. |
There was a problem hiding this comment.
[NITPICK] There are typos and a malformed parenthesis in this sentence: "The initial background thread (or async task( for heartbeat management..." — correct to: "The initial background thread (or async task) for heartbeat management is only launched if a client passes authentication in the connect handler." Also fix 'severs' -> 'servers' and 'heatbeat' -> 'heartbeat'.
### Patches
Version 4.13.2 addresses this issue as follows:
- The initial background thread (or async task) for heartbeat management is only launched if a client passes authentication in the `connect` handler.
- The server now ensures that there is only one background heartbeat thread (or async task) per client at a given point in time. Out of sequence PONG packets are now discarded when an active heartbeat thread is already running.| ### Patches | ||
| Version 4.13.2 addresses this issue as follows: | ||
|
|
||
| - ASGI severs now only load the body of incoming requests into memory after the client is confirmed to be known and authenticated, and the payload size is below the maximum allowed size. Requests that do not comply with these requirements are discarded. |
There was a problem hiding this comment.
[VALIDATION] The description mentions patches but does not give a direct, actionable remediation for maintainers. Add an explicit recommendation (e.g., "Upgrade python-engineio to >= 4.13.2") and list concrete configuration checks (verify ASGI server enforces max payload, set maximum request/body sizes, ensure authentication is validated before loading large bodies). Include a brief test checklist to validate the fix in your deployment.
## Remediation
- Upgrade `python-engineio` to version **4.13.2 or later**.
- Verify your deployment is not using vulnerable configurations without limits:
- For ASGI + long-polling:
- Ensure `max_http_buffer_size` (or equivalent) is explicitly set.
- Confirm the ASGI server is configured to enforce maximum request/body sizes.
- Confirm authentication is performed before loading large request bodies into memory.
- For `aiohttp` WebSocket transport:
- Set an appropriate `max_msg_size` (or equivalent) in the underlying `aiohttp` WebSocket configuration so oversize payloads are rejected before reaching `python-engineio`.
## Deployment test checklist
- [ ] Deploy an environment with `python-engineio>=4.13.2`.
- [ ] Send POST requests with payloads larger than the configured maximum and confirm they are rejected without excessive memory growth.
- [ ] Attempt large WebSocket messages over the `aiohttp` transport and confirm they are rejected at the WebSocket layer.
- [ ] Confirm only authenticated clients can send large payloads and that unauthenticated requests are discarded early.|
|
||
| --- | ||
|
|
||
| <!-- Warning: The suggested title contains the alert rule name. This can expose security information. --> |
There was a problem hiding this comment.
[CRITICAL_BUG] The HTML comment warns that the suggested title contains the alert rule name and that this can expose security information. Do not keep alert rule names or other sensitive identifiers in public issue titles or comments. Redact rule names from public-facing titles and move the full rule identifiers/details to a private security issue or internal tracker.
# Issue #16: Fix code scanning alert - Information exposure through an exception
- **State:** closed
- **Created:** 2024-06-09T07:07:45Z
- **Updated:** 2024-06-09T07:12:42Z
- **Labels:** None
---
<!-- Internal note: Original security alert rule name omitted from public title to avoid exposing sensitive detection details. See internal tracker SEC-XXXX for full rule identifier. -->
Tracking issue for:
- [x] https://github.com/grisuno/LazyOwn/security/code-scanning/6|
Reviewed up to commit:59057fe272767316e8adff2e16f887a93a1443ae Additional SuggestionOthers- The generator script's behavior (replacing the branch on every run and closing previous PRs) is risky/noisy and can cause CI churn or accidentally close work in progress. Change the automation to create timestamped or unique branches (e.g., issues/snapshot/YYYYMMDD_HHMMSS or include run-id) and avoid automatically closing older PRs. Add an opt-in flag to include sensitive details and consider publishing results as CI artifacts instead of committing sensitive snapshots to the repo history.# Example: change branch naming in security_issue_progressive.sh
SNAPSHOT_TS="$(date -u +"%Y%m%d_%H%M%S")"
BRANCH_NAME="security-export/issues_${SNAPSHOT_TS}"
# instead of force-pushing to a fixed branch, create a new one per run
git switch -c "${BRANCH_NAME}"
# ... generate issues snapshot into issues/ ...
git add issues/
git commit -m "Security export ${SNAPSHOT_TS}: issues, Dependabot & CodeScan alerts"
git push origin "${BRANCH_NAME}"
# Optionally open a PR via gh cli without auto-closing previous ones
# gh pr create --base main --head "${BRANCH_NAME}" \
# --title "Security Export ${SNAPSHOT_TS}" \
# --body "Automated security export snapshot for ${SNAPSHOT_TS}."
# For sensitive environments, gate committing behind a flag
if [ "${EXPORT_SENSITIVE_METADATA:-false}" != "true" ]; then
echo "Skipping export of sensitive fields; use EXPORT_SENSITIVE_METADATA=true to include them."
fi |
Automated security export generated on 20260701_095840.
This PR adds a snapshot under
issues/with:issue_<n>.mdissues/dependabot/issues/codescan/issues/README.mdEach run replaces this branch (and closes any previous PR using the same head), so only the latest snapshot is open at any time.
Generated by
security_issue_progressive.sh.