Tag: windows

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.”

“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.

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.