Mastodawn

CVSS 8.8 vulns in ingress-nginx:

ingress-nginx: < v1.13.7
ingress-nginx: < v1.14.3

More info:
1) https://github.com/kubernetes/kubernetes/issues/136677
2) https://github.com/kubernetes/kubernetes/issues/136678
3) https://github.com/kubernetes/kubernetes/issues/136679
4) https://github.com/kubernetes/kubernetes/issues/136680

#devops #kubernetes #infosec

ReynardSec Jan 31

CERT Polska has published a report detailing a coordinated cyberattack against Poland’s energy sector, including renewable energy facilities and a large CHP plant.

https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf

#infosec #cybersecurity #threatintelligence #nationalsecurity #europe #energy #cert

ReynardSec Jan 31

CERT Polska has published a report detailing a coordinated cyberattack against Poland’s energy sector, including renewable energy facilities and a large CHP plant.

https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf

#infosec #cybersecurity #threatintelligence #nationalsecurity #europe #energy #cert

ReynardSec Dec 30

ReynardSec Aug 18, 2025

A grumpy ItSec guy walks through the office when he overhears an exchange of words.

dev0: Big news - we finally upgraded every framework to the latest.
dev1: And the pipeline looks good: SAST, container scan, DAST... all green.
dev0: ItSec won't have anything to nitpick now!

ItSec (walking by): ... and BAC?
dev0: BAC?
ItSec: Broken Access Control [1]. Did you actually test for it?

dev1: What's he on about this time?

Let's learn by example: imagine an endpoint that returns a specific invoice.

GET /api/invoices/123
Authorization: Bearer <token-for-user-A>

User A legitimately fetches invoice 123. Now change only the ID:

GET /api/invoices/124
Authorization: Bearer <token-for-user-A>

If the app returns 200 with User B's data, you've got Broken Access Control (aka IDOR).

Even worse, try a write operation:

PATCH /api/invoices/124
Authorization: Bearer <token-for-user-A>

{"status": "paid"}

If that works... it's a problem.

Access control enforces who can do what on which resource. When it's broken, attackers can act outside their permissions: read others data, modify or delete it, or trigger business functions they shouldn't. In practice, this often comes from missing server-side checks that tie the caller to the resource owner (or an allowed role).

Why your shiny scanners may have missed it:

1) SAST sees code patterns, not ownership semantics (it can't deduce "invoice 124 belongs to User B").
2) DAST usually crawls with one session; it rarely performs cross-identity trials (User A poking at User B's data).
3) CI/CD "green checks" mean dependencies, images, and common vulns look fine - not that your authorization logic is correct.

What can you do?

1) Enforce checks on the server (never rely on the client): before every read/update/delete, verify the caller is the owner or has a permitted role.
2) Centralize authorization in a service/middleware.
3) Prefer opaque, unguessable IDs (UUIDs) over sequential integers, but still enforce server checks (UUIDs are not security).
4) Deny by default. Make allow-lists explicit.

[1] https://owasp.org/Top10/A01_2021-Broken_Access_Control/#description

#webdev #cybersecurity #programming #java #php #nodejs #javascript #infosec

ReynardSec Oct 17

A grumpy ItSec guy walks through the office when he overhears an exchange of words.

devops0: I'll push the new image - just pull "latest"

ItSec (walking by): Careful. "latest" doesn't work the way you think.

devops1: How so?

ItSec: It's just a tag. Whoever pushes the image decides what "latest" points to. Sometimes it's the newest.

First, assume you have a local registry running on localhost:5000 and two Ubuntu images already present: ubuntu:23.04 and ubuntu:22.04. Tag and push both by their actual versions so the registry has explicit versioned tags. Then, on purpose, point latest to 22.04.

# start quick&dirty&unsecure local registry
docker run -d --name registry -p 5000:5000 --restart=always registry:2


# push explicit versions
docker tag ubuntu:23.04 localhost:5000/ubuntu:23.04
docker push localhost:5000/ubuntu:23.04

docker tag ubuntu:22.04 localhost:5000/ubuntu:22.04
docker push localhost:5000/ubuntu:22.04

# intentionally make "latest" refer to 22.04
docker tag ubuntu:22.04 localhost:5000/ubuntu:latest
docker push localhost:5000/ubuntu:latest

Now pull without a tag and see what you actually get. Omitting the tag defaults the client to requesting “:latest”. Because you explicitly set latest to 22.04, that’s exactly what will be pulled and run.

# pull without a tag -> defaults to :latest
docker pull localhost:5000/ubuntu

# verify the version by inspecting inside a container
docker run --rm localhost:5000/ubuntu cat /etc/os-release | grep VERSION=

VERSION="22.04.5 LTS (Jammy Jellyfish)"

If you now retag latest to 23.04 and push again, the same pull with no tag will start returning 23.04. Nothing "automatic" updated it; you changed it yourself by moving the tag.

That's the entire point, latest is a conventional, movable label, not a magical link to the newest software. It can be older than other tags in the same repository if someone set it that way. It can also be missing entirely.

For more grumpy stories visit:
1) https://infosec.exchange/@reynardsec/115093791930794699
2) https://infosec.exchange/@reynardsec/115048607028444198
3) https://infosec.exchange/@reynardsec/115014440095793678
4) https://infosec.exchange/@reynardsec/114912792051851956
5) https://infosec.exchange/@reynardsec/115133293060285123
6) https://infosec.exchange/@reynardsec/115178689445065785
7) https://infosec.exchange/@reynardsec/115253419819097049

#appsec #devops #programming #webdev #docker #containers #cybersecurity #infosec #cloud #sysadmin #sysops #java #php #javascript #node

ReynardSec Oct 2

ReynardSec Aug 20, 2025

Kicking off a 4-part deep dive into AFD.sys on Windows 11: crafting a raw TCP socket, performing the TCP handshake, sending & receiving TCP packets - everything without Winsock.

Part 1: https://leftarcode.com/posts/afd-reverse-engineering-part1/

Part 2: https://leftarcode.com/posts/afd-reverse-engineering-part2/

Part 3: https://leftarcode.com/posts/afd-reverse-engineering-part3/

Part 4: https://leftarcode.com/posts/afd-reverse-engineering-part4/

#reverseengineering #windows #cybersecurity #malware

ReynardSec Oct 2

There is a special circle of hell reserved for corporate intranets. Wikis, conflu and other graveyards… An endless labyrinth of outdated, half-written, barely-searchable pages. They exist only so that, at a convenient moment, the c-level can say: "there is a page on the wiki about this!". Burn it with fire.

ReynardSec Sep 23, 2025

A grumpy ItSec guy walks through the office when he overhears an exchange of words.

devops0: Two containers went rogue last night and starved the whole host.
devops1: What are we supposed to do?

ItSec (walking by): Set limits. It's not rocket science. Docker exposes cgroup controls for CPU, memory, I/O and PIDs. Use them.

The point is: availability is part of security too. Linux control groups allow you to cap, isolate and observe resource usage, which is exactly how Docker enforces container limits for CPU, memory, block I/O and process counts [1]. Let's make it tangible with a small lab. We'll spin a container, install stress-ng, and watch limits in action.

# On the Docker host
docker run -itd --name ubuntu-limits ubuntu:22.04
docker exec -it ubuntu-limits bash

# Inside the container
apt update && apt install -y stress-ng
stress-ng --version

Check how many cores you see, then drive them.

# Inside the container
nproc

# For my host nproc returns 4
stress-ng --cpu 4 --cpu-load 100 --timeout 30s

In another terminal, watch usage from the host.

docker stats

Now clamp CPU for the running container and see the throttle take effect.

docker update ubuntu-limits --cpus=1
docker stats

The --cpus flag is a wrapper over the Linux CFS period/quota; --cpus=1 caps the container at roughly one core worth of time on a multi‑core host.

Memory limits are similar. First tighten RAM and swap, then try to over‑allocate in the container.

# On the host
docker update ubuntu-limits --memory=128m --memory-swap=256m
docker stats

# Inside the container: stays under the cap
stress-ng --vm 1 --vm-bytes 100M --timeout 30s --vm-keep

# Inside the container: tries to exceed; you may see reclaim/pressure instead of success
stress-ng --vm 1 --vm-bytes 300M --timeout 30s --vm-keep

A few memory details matter. --memory is the hard ceiling; --memory-swap controls total RAM+swap available. Setting swap equal to memory disables swap for that container; leaving it unset often allows swap equal to the memory limit; setting -1 allows unlimited swap up to what the host provides.

docker run -it --rm \
  --name demo \
  --cpus=1 \
  --memory=256m \
  --memory-swap=256m \
  --pids-limit=25 \
  ubuntu:22.04 bash

For plain docker compose (non‑Swarm), set service‑level attributes. The Compose Services reference explicitly supports cpus, mem_limit, memswap_limit and pids_limit on services [2].

services:
  api:
    image: ubuntu:22.04
    command: ["sleep","infinity"]
    cpus: "1"              # 50% of one CPU equivalent
    mem_limit: "256m"      # hard RAM limit
    memswap_limit: "256m"  # RAM+swap; equal to mem_limit disables swap
    pids_limit: 50         # max processes inside the container

[1] https://docs.docker.com/engine/containers/resource_constraints/
[2] https://docs.docker.com/reference/compose-file/services/