Tag: container

Supply Chain Attacks – Week 6

Canonical, the proprietor of Ubuntu/Linux, has announced that they’re temporarily suspending automatic registrations within their Snapstore. I often come across a Linux-inspired blog post on the Internet, being deploying PiHole, security hardening PiHoles using Cloudflare’s DNS-over-HTTPS resolver or an unbound instance, etc, and others. And I have come across the phrase “snaps.” I’ve seen Docker container images built with snaps installed, and I don’t understand why. It appears that snaps are akin to app stores, where you install a sandboxed image and the snapd (snap daemon/service) monitors it for updates upstream.

Now, many of us have heard of some Supply Chain attack where Google (in their Play Store), Apple (in their App Store), and Canonical (in the Snapstore) remove a malicious package/app. Even Python, in their PyPI system have been hit by some intrusion by malicious actors.

Supply Chain Attacks

CrowdStrike does a good job explaining:

A supply chain attack is a type of cyberattack that targets a trusted third-party vendor who offers services or software vital to the supply chain.

Software supply chain attacks inject malicious code into an application in order to infect all users of an app, while hardware supply chain attacks compromise physical components for the same purpose.

CrowdStrike: What Is a Supply Chain Attack?

The above examples, in my links, are examples of software supply chain attacks — targetting PyPI, Play Store, App Store, etc. Although CrowdStrike supplies the SolarWind supply chain attack, it’s not exclusively software. There are instances of hardware supply chain attacks, namely Supermicro via Chinese spies.

Conclusion

Aside from awareness, and listening to disclosures of app stores and other dependencies, users are generally the least able to mitigate these exploits, and often times, app stores are informed by users of malicious activities by their solution/product. Also, if you’re a developer (maker of software products), you’ll have dependencies and it’s good to stay vigilant on what you’re including in your software.

I hope this blog post helped raise awareness of this new attack vector. The really tragedy is that it feels like malicious actors are getting better, definitely more prolific in their attempts. So, uh, yeah – keep an ear out for security news, try and sanitize your environments (when you can), and relay the news of this attack type when you can.

Distroless and Living Off the Land – Week 4

DEF CON 31 – Exploring Linux Memory Manipulation for Stealth and Evasion – Polop, Gutierrez

I got inspiration for this posting while watching a DEFCON 31 video, which I linked above.

Distroless

The container that these gray hats used were called “distroless” containers. For those unfamiliar with distros (or distributions), here is my short summary about distributions:

Distributions (or distros) are Linux systems that establish a layout of the file system, and they’re managed by a package manager for their version of how the file system is laid out on the hard disk. In my opinion, Linux hosts have a few root distributions: Red Hat (.rpm), Debian (.deb), Arch, and source — like on Gentoo.

The sea of distributions, which you can try through DistroWatch, has several variations — like Ubuntu, which is a Debian child, and Onion, which is another Debian child for security tools. Both of these examples use the Debian package manager (aptitude).

Many modern operating systems have two distinct modes within the system: user space and kernel space. For GNU/Linux systems, the Linux kernel handles I/O, memory and device management, and interrupts, where GNU (guh-NOO) core utilities comprise the bulk of its user space binaries — for example, cat, sed, etc. (basically binaries that are shared across “Linux” hosts). When you write Bourne (SH) or Bourne-Again Shell (BASH) scripts on Linux, you rely on GNU core utilities to maintain compatibility with each system so that your script can run on many different hosts.

NOTE: Although *BSD hosts have the same binaries, like cat, awk, sed, and others, the source code for BSD user space binaries is maintained with its kernel; yes, *BSD hosts are distinct from Linux. A *BSD (FreeBSD, OpenBSD, NetBSD, DragonflyBSD) host is not guaranteed to be completely compatible with Linux scripts because argument flags and performance may differ. Although *BSD hosts share the ELF binary format, they are not compatible. If I want to run Linux binaries on FreeBSD, I have to establish a compatibility layer, and that’s not totally guaranteed to work.

So, why are they called “distroless containers?” It’s because they’re stripped of GNU core utility binaries and package management utilities. In order to perform functions within a distroless container, as the DEFCON video establishes, you need to establish a reverse shell in order to make syscalls or install shell capability within memory, which can then accept remote commands and execute syscalls. The point of distroless containers is to hedge against “living off the land” attacks,” which I’m about to discuss next.

Living Off the Land

“Living Off the Land” (attacks) is when attackers use installed system binaries to perform reconnaissance, exploitation, and ex-filtration activities. Antivirus, and similar endpoint protections, normally perform scans on binaries that are downloaded on to the system, and they often have databases of known viruses, and heuristics, etc, which can detect when a file is a known bad and then block its execution.

In living off the land attacks, the binaries used in their attacks are “known good” versions already installed on the system; these known good binaries are usually permitted to operate on the operating system, which may then go unnoticed by the user and possibly any installed endpoint protection. So, many times, a living off the land may deploy a script — like PowerShell and BASH — that uses system binaries to perform nefarious activities. It may seem invisible, but some (not all) may block execution of scripts.

On Windows, there are (un)fortunately several scripting systems: command-prompt, which is a MS-DOS carry-over, PowerShell, and VBscript. VBscript and command-prompt don’t offer much for mitigation measures on a Windows system, aside from whether or not user permissions permit execution of a particular method. For example, a regular user may not have access to modify COM+ objects, but an administrator may. That’s why a good security measure is always “least privileges.” In PowerShell, Microsoft was more security aware to implement execution policies; for more information, please Get-Help about_Execution_Policies within a PowerShell session.

On Linux hosts, shells — like VBscript and command-prompt — don’t offer much for mitigation; the only mitigations, really, in Linux systems is good administration, like implementing “least privileges” (e.g. not running as root), ensuring that sudoers do not use “NOPASSWD:,”, etc. There is something called rbash, which is a version of BASH that offers restricted operations. I think it restricts it from opening sockets, unlike normal bash and some other operations? I really need to explore more about it.

Now, as in the DEFCON video, you could deploy systems within a distroless container, but this is really only for binaries — not normal users. But like, as in the DEFCON video, if you allow PHP (and other Web CGI — like Perl, Python, et al) as a binary, “living off the land” becomes much easier.

Closing Remarks

It would seem that although a “distroless container” may slow a “living off the land” attack, it doesn’t stop it completely. And even as I pointed out, if your distroless container deploys some CGI — a scripting environment, it’s most assuredly not protected at all since many scripting languages afford methods of opening sockets or reverse shell attacks.

Why are we concerned about this distroless container exploit? Many private cloud vendors, such as Amazon, are heavily invested in the container space. Amazon has a container host called, Bottlerocket, which is comparable to Fedora’s CoreOS. These are dedicated hosts that run containers. But it’s not impossible to escape containers, as provided in this tutorial Docker Breakout / Privilege Escalation or through this article, Abusing the Access to Mount Namespaces through /proc/pid/root. Though these seem to be relevant to Docker, the exploits may be attempted on these other hosts to see whether the vulnerability still persisted through their implemented container environments.