Nothing About E2E Encryption – Week 13

Nothing, the vendor of Nothing Chat a re-skin of Sunbird app, was discovered to provide a subpar E2E encryption chat app for Android users, in this ArsTechnica.com article: https://arstechnica.com/gadgets/2023/11/nothings-imessage-app-was-a-security-catastrophe-taken-down-in-24-hours/ Nothing has suspended their app, until they can fix their security issues, which were discovered by the broader Internet community.

The following issues were identified with Nothing’s E2E app:

  1. Apple ID and password shared with site,
  2. Sunbird actually logged and stored messages in plain text on both the error reporting software Sentry and in a Firebase store,
  3. Authentication tokens were sent over unencrypted HTTP (TCP-80/HTTP) so this token could be intercepted and used to read your messages, and
  4. “When a message or an attachment is received by a user, they are unencrypted on the server side until the client sends a request acknowledging, and deleting them from the database. This means that an attacker subscribed to the Firebase Realtime DB will always be able to access the messages before or at the moment they are read by the user.” 

Conclusion

Per the article, “Içöz recommends that any Sunbird/Nothing Chat users change their Apple password now, revoke Sunbird’s session, and ‘assume your data is already compromised.'” Frankly, I’m amazed the Apple and Play Store don’t start having developers answer a quiz to determine whether their app merits posting into their “Walled Garden,” but perhaps, they already do and this is merely a response by the Internet community that does check each apps claims regarding “security standards” or claims.

For those interested, there are several things they should be ensuring (encryption) secure data “at rest,” “in use” (in memory), and “in motion.”

Security “at rest” is as you’d expect. It ensures that the data stored on the hard drive, when it’s not part of the “hot”/”active” data set is properly encrypted and secured. Security “in use” (or in memory) is ensuring that snooping can’t occur while the user is using it; it’s often associated with sessions. Unfortunately, the Intel Spectre, Intel Meltdown, and “AMD RETbleed” vulnerabilities open this problem because if the processor can be attacked to divulge data in (active) memory, all data on the system is vulnerable. In some cases, Intel or AMD can release microcode for x86 Chipset architectures so check with your motherboard vendor to ensure proper U/EFI (or BIOS) patching; ARM/RISC-V systems haven’t been identified as being vulnerable to these attacks, yet. And finally, security “in motion” is associated with transport data; security on this perspective is often handled through TLS/SSL encryption of the transport layer within the TCP/IP stack.

Maine Hit by MOVEit Supply Chain Attack – Week 12

On November 9th, APNews reports that Maine has informed resident-users that a MOVEit attack caused a breach. In October, 9to5mac.com wrote about a MOVEit 0day that was making in-roads.

Ransomware is now implementing a double-extortion method to get victims to pay its ransoms. Normally, a company or organization might be able to restore from a backup and thereby avoid paying the ransom that was requested for them to restore their services; however, ransomware is now adding the threat of release of information, if that ransom hasn’t been paid.

In 9to5Mac’s 2023 State of Ransomware, the USA is considered the highest target with ransomware. It is 7x more likely to be targeted with ransomware than the next highest countries. Here’s Malwarebytes’ assessment on why CL0P is outpacing Lockbit:

The drive behind the sudden change? CL0P used separate zero-days in GoAnywhere MFT and MOVEit Transfer to gain an edge. This gave them the ability to launch an unprecedented number of attacks within a short time frame and across a massive scale.

The use of zero-day vulnerabilities by ransomware groups like CL0P may trigger a significant shift in ransomware strategies, mirroring the adoption of the “double extortion” tactic in 2019.

Malwarebytes, https://9to5mac.com/2023/08/04/us-number-one-for-ransomware-attacks/

Unfortunately, I don’t foresee any of this easing up. With ransomware crews achieving successes, they’ll probably continue with this activity. In some areas online, I’m starting to hear that the best recommendation (due to these breaches of information) is to freeze your credit, and unthaw it temporarily when shopping. Why is this becoming a common recommendation? With so many breaches, it’s more probable that your information is available. It might also be helpful if the government would implement some protections with teeth to increase the deterrence.

iOS 17 Users Are Vulnerable to Bluetooth Flipper Zero SPAM Flood Attacks – Week 11

TL;DR – The only method to avoid this attack, while on iOS 17, is to disable Bluetooth per https://www.theverge.com/2023/11/3/23944901/apple-iphone-ios-17-flipper-zero-attack-bluetooth The good news is that previous versions of iOS, such as 16, have not been demonstrated to be vulnerable.

The Flipper Zero, touted as a Swiss Army knife for radio attacks, has demonstrated that with a custom firmware on the Flipper Zero, it can attack unsuspecting iOS 17 users.

Van der Ham discovered that the attacker, another passenger on the train, was using a Flipper Zero device with custom firmware to send a combination of Bluetooth low energy (BLE) alerts to nearby iPhone handsets running iOS 17

The Flipper Zero is “a small orange and white plastic gadget with a 1.4-inch display that looks like it could be a child’s toy. The Flipper Zero is a multi-tool for hacking, as it talks to sub-1GHz devices like old garage doors, RFID devices, NFC cards, infrared devices, and of course, Bluetooth devices.”

Although the article is geared toward awareness of iOS users, Android and Windows laptop users can also experience a similar issue; however, Android and Windows users are less likely to require a restart. “On Android, head to Settings → Google → Nearby Share, and turn the toggle on Show notification to the ‘Off‘ position.”

Passkeys – Week 10

In recent news, Amazon is allowing users to adopt passkeys. I wanted to understand a little more about Passkeys, and how Passkeys are supposed to work.

What About Passwords?

Passwords are currently here to stay, and you should still exercise good password hygiene. Good password hygiene/protocol can be summarized as follows:

  • Create strong passwords
  • Avoid repeating passwords
  • Do not share passwords
  • Avoid leaving passwords in unsafe areas — don’t write them on a memo pad
  • Use a Password Manager, whenever possible

About Creating Strong Passwords

Strong passwords have entropy, basically the probability of a hacker determining the password. Password policies seek to curb users toward creating better passwords by increasing the symbol selection: letters, digits, and symbols. But that’s part of the battle. To decrease the chance of determining passwords, users should also create passwords over 8 characters, and they should avoid easily guessable ones as well.

How Passkeys Work

In the simplest explanation, it works similarly to public-key infrastructure whereby it uses asymmetric encryption. Asymmetric encryption works by using two keys: a private key and a public key. A real-life demonstration of asymmetric encryption is SSL/TLS used on Web sites connecting over HTTPS. The public key is used to encrypt the message and the private key decrypts the message.

So, since the Passkey system creates this asymmetric key pair, it alleviates the user of trying to formulate a strong cryptographic key. It is also very difficult for hackers to gain access to it since the private key is stored on the device’s keychain, and the Passkey system creates a new key pair during initial configuration. As it’s kept on the device’s keychain, it might be prone to loss of device or device failure, which is where cloud services can help by using things like Apple’s iCloud and similar for each mobile vendor.

Conclusion

Although I am optimistic of this new method of authentication, I do have apprehension, and I hope that the restoration methods are well-documented. I’m sure passwords and MFA (multi-factor authentication) will remain as a feasible restore procedure for a while.

One issue that is an omnipresent problem is user adoption and user education. Users have a diverse set of backgrounds, and the common user “just wants it to work” and they really don’t care how. Plus, there are users who will be apprehensive of adopting new methods of authentication, and additionally, they’re probably confidently locked (and/or obstinate) into their “tried-and-true method.”

The next hurdle is also adoption by companies deploying them. It takes training, and I’ve seen some really complicated deployments for something as seemingly simple as multi-factor authentication — for whatever reason, possibly poor design by the vendor?

Anyhow, it may be slow or fast adoption. Data breaches of client information may intimidate some to the switch, but not everyone will switch. We shall see how this goes.

DHS (Department of Homeland Security) Confirms Your Privacy Is No Longer Safe – Week 9

In ComputerWorld’s article, https://www.computerworld.com/article/3708251/homeland-security-confirms-your-privacy-is-no-longer-safe.html, they confirm that some Federal departments have not been successful at protections articulated in E-Government Act of 2002 and the Homeland Security Act of 2002.

There are no remediation yet; however, users can go into their Location Services and ensure that apps are only permitted access to Location Services, as appropriate. Ideally, you should work from a positive security model and lock them all down and return their permissions as they come up and are vetted, but that seems very challenging. I’m surprised, at this point, Google and Apple’s Cloud service doesn’t have an applet to modify certain privacy settings more easily.

“Let’s Encrypt” Pros and Cons – Week 8

There are plenty of old blog posts on the Internet regarding its benefits from an administrator point, but I want to speculate about the pros and cons from the perspective of a malicious actor.

Let’s Encrypt through its certbot or ACME client program allows an administrator to spin up a web site and achieve TLS from the Internet. It helps low budget administrators get certificates for their Web sites, which are recognize by a registered 3rd Party certification authority. This permits Web sites, such as my own to have a valid Web site. It also does so in an automated manner, meaning it’s also low touch from an administration stand point — effectively, set it and forget it.

What is ACME (certbot)?

In order to speculate on the pros and cons, let’s review what the ACME/certbot program allows an administrator to do. Once the Web site and its hosting/service software has been configured, the administrator then configures the certbot. The certbot is a utility software on the server that connects to the Let’s Encrypt servers, submits its certificate request, receives the signed certificate, updates the Web server service/daemon configuration, and then restarts or reloads the services.

Pros/Benefits

Low cost

When you configure your certbot, you need at least four things:

  1. an email address,
  2. a valid DNS hostname,
  3. Internet address, and
  4. administrative know-how.

An email addresses can be free, or it can be part of an organization; effectively, it allows Let’s Encrypt (as an organization) to contact the administrator if an issue is detected with the certificates or other communications. Email addresses are so easy to come by, it’s one of the many reasons for the proliferation of SPAM email. It can also be spoofed, and I receive many “malformed” emails so through compatibility reasons, it’s easy to even masquerade. If I were Let’s Encrypt, I’d add a verification step whereby the certificate isn’t registered when the administrator or user doesn’t validate it.

A valid DNS is fairly cheap, and for hosts within DHCP-assigned pools — like many ISPs, you can purchase Dynamic DNS. I did, and I am using it for genuine services. Do you like my blog? Generally, the certbot works by coordinating its signing using the host name in the request, like a callback. So, as long as the DNS host name has a forward resolving address, it’ll work fine with certbot.

The Internet address is a given so long as it’s globally accessible. RFC 1918, and other private IP address spaces, won’t work; however, the host can have a private address, and as long as the firewall permits port forwarding, the certbot should have little issue configuring the site.

Everybody can search the Web using Google, or another Web search service. There is an abundant amount of How-To blogs. Also, there are a lot of YouTube videos that can walk through configuration steps. Additionally, the certbot also comes with manual pages. Once you’ve installed the Web host, and the certbot, you can read the manual via man certbot I will say that understanding networks and having practice is greatly beneficial. Ultimately, the issue of “administrative know-how” boils down to time and practice.

Low “touch” and/or hands free

Once the certbot has been configured, all you need to do is run it on a periodic basis to refresh the certificates. I have a cron task that checks in with Let’s Encrypt on a weekly basis. If the certbot needs to change the certificate because it expired, it does so during check-in. There are also protocols for when a certificate or key becomes compromised; that’s not really hands free, but it’s there.

Provides Valid TLS Certificates

In the link that I provide, certbot does sign valid certificates. Common browsers, such as Mozilla Firefox, Google Chrome, Microsoft Edge, and etc, have Let’s Encrypt as a valid Certificate Authority. The link also talks about the difference between EV, OV, and DV; these are Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). In certbot’s basic form, it will perform Domain Validation; that is, during configuration, the Let’s Encrypt server will connect back to the host and perform some Web requests. When I was using relayd and httpd (on OpenBSD), I had to ensure that a path requested by certbot would not get an HTTP/302 Redirect while it performed these activities.

Quick Host Name Changes

As part of my dynamic DNS, I could register up to 25 host names. This is a fairly large pool, and when I spun up this WordPress instance, it didn’t take much to update certbot — merely updating the Web VirtualHosts and re-run the certbot.

Cons/Problems

Administrative Complexity

Again, from a malicious/offensive platform, spinning up a host, configuring its services, configuring the certbot, and possibly purchasing DNS and registrar is going to be costly. Some of it can be reduced, namely it could be possible to script these deployments so it can be pipelined; it can be reduced using CMS — like Ansible, but that’s added complexity. Or you could containerize the malicious deployment, which reduces spin up time and can simply be deployed on a container service.

“Paper Trail”

The registrar portion is the most paper trailing part of this — usually involving some form of credit card, and if a SaaS is used, it would also create a paper trail. It is possible to play a shell game, but that’s difficult.

Slow Reaping of Host Names

Since I haven’t attempted to spin down a host name, yet, I can’t comment about how long it takes to reap a host name. If I had to guess, Let’s Encrypt should invalidate and re-issue a new certificate once the Subject Alternative Name field needs updating. It wouldn’t surprise me if too many host name changes on Dynamic DNS causes a red flag to be risen, and I haven’t tested that to see if there are any limits. It may be articulated in a privacy policy, but I’d need to re-read them.

Easy Target to (D)DoS

If the host is done privately, on a private premises, denial-of-service would be very easy to apply on a single host. This is why IaaS is often preferred because the services generally offer some (D)DoS protection. Once the forwarding resolution name has been claimed, it basically helps attackers; it, effectively, paints a bullseye on the perpetrator when hosted privately.

Conclusion

It feels as though using certbot and dynamic or traditional DNS would lead to a higher probability of detection and mitigation by Blue Teams. If I were a Red Team crew hosting some node for collecting reconnaissance, I’d definitely try poisoning Web hosts by implementing some XSS or other persistence method. Most users don’t pay much attention, as long as the Web host has a green light, and this passivity on end-users is often coupled with few methods of reporting the situation. There is no Help Desk and CISO for the Web.

Thousands of Android/TV Ship with Malware – Week 7

It would appear that the supply chain has come under attack again for Android users, https://arstechnica.com/security/2023/10/thousands-of-android-devices-come-with-unkillable-backdoor-preinstalled/ And it’s confirmed by MalwareBytes: https://www.malwarebytes.com/blog/news/2023/01/preinstalled-malware-infested-t95-tv-box-from-amazon

Indicators of Compromise

Root Access

It would appear that in the Android About system settings, a “root switch” has been added to compromised devices. If this is found, then it’s safe to initiate a return or replacement.

Shell Games

If you connect to the device to adb, and you run the shell utility. The compromised systems (via adb shell pm list packages -f) are identifying as “walleye” within the shell, which is an old Google Pixel 2

CoreJava Directories Ought Not Be There

On the Android’s filesystems, compomised hosts have a directory called: /data/system/Corejava. It contains malicious file objects, Looking at the VirusTotal results of the Corejava classes.dex found in my own T95 TV box aligned with it being a Trojan Downloader. The clearest evidence of this were URLs in the code. One of them was a malicious URL associated with other malicious DEX files and APKs:

hxxps://dy.kr.wildpettykiwi.info/dykr/update

Conclusion

The MalwareByes article: https://www.malwarebytes.com/blog/news/2023/01/preinstalled-malware-infested-t95-tv-box-from-amazon offers steps to remediate this on the compromised device. Despite the fact that this may be a dirty deal, it seems common for unsuspecting users on a budget to fall victim to these attacks.

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:

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.

Advice Toward Cybersecurity Education – Week 5

I recommend Krebs on Security as a blog worth reviewing. He highlights items, like card skimmers, value of a hacked email, the value of a hacked PC, and many other items on cyber security. I was curious about his blogged advice for cyber security career seekers, and here is my attempt to summarize his post: Thinking of a Cybersecurity Career? Read this.

1. Practical hands-on experience

It is wise to pursue alternative learning platforms, such as Hack The Box, etc. because it can help you stand out. It will also impress future hiring since they can see initiative as well as see you as a self learning enthusiast.

I would also advise continuing with posting quality blog posts because you can a) refer to it when you’ve forgotten something and b) it’ll help you learn how to document things well. After working in a Security Operations Center (SOC), it was very common to post how-tos and the likes, especially SOPs.

2. A deep understanding of networking

This one has many facets to it. Fundamentally, you should understand an overview of the mechanisms in a packet-switched network, and how the OSI/TCP-IP Models interplay with each other. As you’ve looked at packet analysis in the week 4 labs, it’s a good start. But I recommend dissecting more packet captures. Here’s something to learn: encapsulation. An HTTP packet sent over an SSL packet is a segment within a TCP packet, which is a segment of an IP packet that operates over an Ethernet packet. The common MTU (Maximum Transmit units) is 1500 bytes. How big are the Link-Local Addresses? What does a TCP and UDP header occupy? Can ARP poisoning impact a separate network segment/VLAN? What is a VLAN? What is a broadcast domain? What is the difference between a network hub, a network switch, and a network router? What is a proxy? What is the different between a forward and reverse proxy?

The reason why this is so important is because if you have a strong foundation in networks, you can either articulate or determine the attack vector. At my logistics work, my workplace got blackballed because the IP address was getting marked as a GameOver/Zeus target. I literally deep-dived into the companies packets to find the node that was causing our company email to get blocked.

If you want to experience my PowerPoint that I shared with my company, let me know by email and we can setup a Zoom to demonstrate.

3. Platform experience

In this past week’s lab, we learned about User Access Controls in Windows, the importance of groups, and how to configure them and validate that they’re working as expected. It is good to be super familiar with Windows because it is by far the most targeted platform, mainly because its users are seen as money bags compared to Linux users. But no platform is safe. Malware on Linux is on the rise; CrowdStrike said there was a 35% increase in Linux-Targeted Malware in 2021. HelpNet Security claims coinminers, web shells and ransomware made up 56% of malware targeting Linux systems in H1 2021. macOS is little different, and its often targeted because users are naive, and they’re seen as viable targets as well.

Bottom line? Understand security features of each platform, and learn how to work with them. You can VM any Linux or *BSD platform because their licenses are very permissive. macOS platform does require Apple hardware per its EULA, and Windows does permit a 30-day evaluation, which can be a great way to VM the system and learn its security features.

4. Exploit knowledge

As this course continues, I hope you’re exploring articles about how a particular worm, Trojan, etc. was said to work. And get used to this because after working in a SOC, you may as well go through 10 blogs a week and review three different exploits. How does a SOC determine which threat to hunt? They usually take their cues from the news cycle, but sometimes, they will look at something that seems to have cooled in the public eye, but it could be a low effort attack that may be interesting.

5. Programming Experience

Luckily, at Metropolitan State University, it would seem that students can be exposed to a rich set of programming languages. As a Computer Science major, we’re primarily focused on Java; however, I have been in classes that have used C, Assembly, and Scheme as well. Although there is the opportunity, are you investing enough time to explore those other programming languages? Have you created a Linked List in C as well as Java?

Also, don’t neglect Shell scripting. As in my previous post, “living off the land” is a very real attack method, and understanding the (common) commands can help you with determining how to protect assets.

Conclusion

Although these are hits on Krebs blog, I advise you to stay curious and explore whenever free time is available. Your self-paced learning in this field could lead to better hiring outcomes. Oops, I forgot one last thing; don’t forget to network with peers. Honestly, it could mean the difference between getting an interview and not.

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.