The Vulnerability of Cybersecurity
Yeah, judging by the title, it seems I’ve been pwned. I’m not a cybersecurity expert, but I’ve been pivoting to learn more about creating secure systems as I increasingly interface with the web.
Lately, I keep hearing about breaches from these major silos, and it’s gotten me thinking. What the HELL! I feel increasingly vulnerable as we grow within these ecosystems. Over time, we develop a trust in these services, paid or not, only to find they often become vectors of exploitation. An enormous amount of our data is stored within these giant silos, and it’s frustrating because it feels like we have little to no choice but to use much of the half-baked infrastructure that’s out there. We live in a world where security is seen as a liability that can be written off. Many of these companies perform a cost-risk analysis that favors continued ignorance since it’s more profitable than investing in securing their systems. It seems they’re contingent on just paying whatever fines come with their intentional ignorance. I’ll stop ranting, but the gist of this post is to ultimately say that moving forward, I intend to be responsible for my systems and not rely on the black-box infrastructure of others.
The Awakening: Recognizing the Threat
It began with a routine check of my system files and a flag was raised after looking into some of my firewall configs.
Step 1: Identifying the Culprit
Some of the tools that helped assist me on malware identifcation.
- UFW Scan: A deep dive into the world of open ports.
- Wireshark: Turning network traffic into a decipherable story.
- System Logs: Sifting through /var/logs for anomalies.
- User Accounts: Investigating /etc/passwd for uninvited guests.
- Process Monitoring: Keeping an eye on the CPU’s activities with htop.
- Malware and Rootkit Scans: Deploying ClamAV and RKHunter in a digital hunt.
Step 2: Isolation and Backup
I disconnected my device from the network, creating a digital quarantine. Then came the backup process. Side note: I discovered a budget-friendly backup solution – an M2 NVMe SSD with an enclosure. Functional, economical, and surprisingly easy.
Firewall mishaves
My firewall configurations were a patchwork of permissions and restrictions. But a particular port, 1337, flagged by a foreign IP, seemed out of place. This kicked off another round of investigations.
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
Anywhere ALLOW IN 192.168.0.0/24
6881:6891/tcp (Deluge) ALLOW IN Anywhere
22 ALLOW IN Anywhere
23/tcp ALLOW IN Anywhere
51413 (Transmission) ALLOW IN Anywhere
1965 ALLOW IN Anywhere
1:65535/tcp ALLOW IN Anywhere
631/tcp DENY IN Anywhere
1337 ALLOW IN 123.45.67.89
631 ALLOW IN Anywhere
1337 DENY IN Anywhere
6881:6891/tcp (Deluge (v6)) ALLOW IN Anywhere (v6)
22 (v6) LIMIT IN Anywhere (v6)
51413 (Transmission (v6)) ALLOW IN Anywhere (v6)
1965 (v6) ALLOW IN Anywhere (v6)
1:65535/tcp (v6) ALLOW IN Anywhere (v6)
631/tcp (v6) DENY IN Anywhere (v6)
631 (v6) ALLOW IN Anywhere (v6)
1337 (v6) DENY IN Anywhere (v6)
1337 ALLOW OUT 123.45.67.89
1337 DENY OUT Anywhere
1337 (v6) DENY OUT Anywhere (v6)
More Forensics
- Firewall Restructuring: Revising rules for tighter security.
- The 1337 Enigma: A digital breadcrumb hinting at unauthorized access.
- The ‘Nobody’ User: A mysterious presence in the /etc/passwd file.
- Network Surveillance: Employing Wireshark and Snort for vigilant monitoring.
Here is a warning of a potential rootkit/.
The Hard Decision: System Wipe
In the end, I opted for a complete system reset – a clean slate approach. It was a tough call but a necessary one in the pursuit of digital cleanliness.
Reflection and Forward Steps
This ordeal was more than a cybersecurity crash course. It was a wake-up call to the realities of our digital existence. Next, I plan to document my journey in creating a robust backup system using Rsync and Rclone. Stay tuned for more adventures in the land of digital defense.
Microsoft’s In-Depth Release on Linux Trojan
Recently, Microsoft released an in-depth report following a spike in activity involving a Trojan on Linux machines. This Trojan was first discovered by the research group MalwareMustDie in 2014. For more details, you can read about the Trojan in their article, “Rise in XorDdos: A Deeper Look at the Stealthy DDoS Malware Targeting Linux Devices.”
Concerning Discovery in ‘etc/passwd’ File
The last thing that worried me, and I think might have been a false positive, concerned a user entry in my etc/passwd file. This was particularly concerning:
Surprisingly, I couldn’t find any detailed information on what this meant. At first glance, I thought it indicated a buffer overflow causing escalated privileges to the kernel. If anyone reading this has a better explanation of what process is responsible for this user, I’d appreciate it. From my brief research, it seems the UID 65534 is the overflow user, who is the root super-user. This ‘nobody’ user should be used exclusively with NFS (Network File Sharing), which is odd since I don’t recall installing or using that service. My hunch, giving the benefit of the doubt, is that it might be related to the Castor & Gemini server I was running. But again, I didn’t want to go down that rabbit hole. I was just looking for any indicators of suspicious activity.
Monitoring Network Activity
Lastly, since the Trojan was used for Distributed Denial of Service (DDoS) attacks, I thought it prudent to monitor network activity. I’ve been sniffing packets using Wireshark and also downloaded Snort as a precautionary measure.
