Tag: cybr332

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.

Car Privacy Not Included – Week 3

Although I concede that this isn’t specifically cyber security, privacy is almost synonymous with security in general, and in that spirit, I encountered this review of Car Privacy Policies: It’s Official: Cars Are the Worst Product Category We Have Ever Reviewed for Privacy

In their conclusions, they summarize that consumers really don’t have choices among brands; “they’re all bad.”

Like we mentioned, all of the cars we researched earned our *Privacy Not Included warning label. All of the car brands we researched got our “data use” and “security” dings — and most earned dings for poor data control and bad track records too! We can’t stress enough how bad and not normal this is for an entire product guide to earn warning labels.

The worst problem is that the review could not conclude or even test how data is being secured on just the car, itself, or how companies are managing the data that they do collect. And the privacy policies are implicit since who reads the Privacy Policy of a car that they’re boarding. To add to the problem, Minnesota has enacted legislation in 2022: https://www.revisor.mn.gov/statutes/cite/169.475 that requires motorists to use hands-free connectivity with their vehicle, which compounds this issue because motorists are compelled to connect their smart phones if they intend to use it while the vehicle is in operation on motorways.

Many people have lifestyles that require driving. So unlike a smart faucet or voice assistant, you don’t have the same freedom to opt out of the whole thing and not drive a car.

Well – I am grateful that my car is most assuredly, “dumb.” In most cases, the on-board Bluetooth merely permits interoperability for hands-free operation, like making a phone call or changing audio tracks.

If you want to join Mozilla’s petition to get this fixed, you can do so: https://foundation.mozilla.org/en/privacynotincluded/articles/car-companies-stop-your-huge-data-collection-programs-en/

VPNs Still Don’t Work – Week 2

Original posting by Feisty Duck: Feisty Duck: VPNs Still Don’t Work, which based their Newsletter from TunnelCrack.

The Feisty Duck reiterates TunnelCrack’s conclusions so I’ll try to articulate the two vulnerabilities/attack vectors identified by TunnelCrack. The first attack dubbed “LocalNet Attack” is where the malicious actor clones a WiFi hotspot, which are commonly available in public spaces, like the WiFi at StarBucks. The user, thinking that this is owned and operated by the establishment, foolishly connects to it, where the hacker assigns an IP address from their private pool. The malicious actor can then exploit the vulnerability because VPNs are notorious for permitting LAN address communication. When the user tries to connect with a site, the malicious actor injects or monitors web traffic between its unsuspecting user and a legitimate site.

The second attack, dubbed “ServerIP Attack,” is a little more complex, but the principle is the same; “while establishing the VPN connection, the victim will add a routing rule so that all traffic to the VPN server, in this case the spoofed IP address 1.2.3.4, is sent outside the VPN tunnel.” And because VPNs don’t re-encrypt traffic between the user and its VPN server, the user connects to an unsafe point, which leaks information.

The TunnelCrack team did testing for a broad set of VPN clients and platforms, and they discovered that Apple users are most susceptible, whereas other platforms and VPN clients did better; Android, after version 12, is least affected.

The reason why Feisty Duck posted about these attacks is because they’re a good source for SSL/TLS configuration. Feisty Duck concludes that when a “combination of TLS, valid certificates, and HTTP Strict Transport Security” are implemented, users are far better protected from these exploits. It’s easy to spoof DNS and masquerade as a legitimate server until TLS is properly vetted since most 3rd Parties, like Verisign and GoDaddy, protect their private keys like Crown Jewels.

I did notice that from the TunnelCrack post that VPNs are also susceptible since, like in OpenVPN, the host configuration keyword is often accompanied by a DNS hostname, which can easily be spoofed.

One thing that I didn’t see in these blog posts/newletters was mention of DNSSEC, but I guess, DNS — when it performs a forward lookup — may not be running the gauntlet to validate that the DNS reply is using properly configured DNSSEC; it’s probably less likely.

Continue reading VPNs Still Don’t Work – Week 2

Reverse Shells – Week 1

I was on Reddit.com, and I encountered a question regarding reverse shells. So, I pulled up this resource: https://marketsplash.com/tutorials/bash-shell/reverse-shell-bash/ regarding reverse shells.

The OP (original poster) of the question was asking about reverse shells for the purpose of testing the security awareness of his tool, like Whitehat Sentinel, CrowdStrike FalconHost and Tenable.IO. The security tools are classed as “network vulnerability scanners.” In some cases, the vulnerability scanner will connect with a host, and execute a reverse shell to execute its test(s). This is a valuable and genuine use for reverse shells; however, attackers also use this method to deploy payloads.

I have used PiHole to blackhole selected DNS requests, but I always cringe at their “One-Step Automated Install” method: https://github.com/pi-hole/pi-hole/#one-step-automated-install, where you pipe a downloaded script into BASH. I would advise users who encounter this installation method to download the script, run it through a virus scanner — perhaps it happened automatically during download, then if you’re virus scanner gives its blessing, you can just execute the file like any other BASH shell.