3 ms·
Thank you for responding. We searched the whole system for authorized_keys files and found one created in a /var/lib/redis/ of a staging container (with no fi
by gopi_ar 10y ago
Thank you for responding.
We searched the whole system for authorized_keys files and found one created in a /var/lib/redis/ of a staging container (with no firewall) on this host. We then came across the redis vulnerability https://kevinchen.co/blog/postmortem-server-compromised/ https://kevinchen.co/blog/postmortem-server-compromised/ . A junior dev had spawned this container without help from dev-ops and hence left ports open.
What doesn't make sense to us is how this daemon (yam) was running under a statd username when the container doesn't have such a user, but the host does? Are LXC containers able to run daemons on the host?
- jmgao 10y ago> What doesn't make sense to us is how this daemon (yam) was running under a statd username when the container doesn't have such a user, but the host does? Are LXC containers able to run daemons on the host? This is because usernames don't exist, as far as the kernel's concerned. ps is resolving the process's UID to the corresponding name for the outside context, not the one inside the container.
- gopi_ar 10y agoThis makes sense, we can rest easy knowing they didn't break out of the container. Thanks!
- arpa 10y agoWell, it is always possible that attacker broke out of the container, as the container is still running under the same kernel, only its process(es) are chrooted + namespaced. Containerized "root" supposedly has its' privileges cut down, but if the kernel is exploitable...