Preamble
1. Dante Complete
This month I finally got around to completing the Dante Prolab offered by HackTheBox; you can read about my impression of the lab in an earlier post. In observance of the platform’s Use of Service agreement, I won’t detail the particulars involved; that said, this lab environment was an excellent way to follow-up my OSCP examination; in many ways, it complemented the skills being developed, such as pivoting.
A less distracted (or more talented) person would certainly be able to complete the lab in a fraction of the time I did it in. But between personal responsibilities at home, work, and grad school, I could only afford to attack the targets for a few hours every other night.
Notably, completing the lab qualified me to jump ahead of the waiting queue to participate in the bug bounty platform Synack. While web application testing and bug bounties haven’t been in the scope of my expertise, I’m interested in seeing how this manifests.
2. The Daily
I really like hearing from The Daily; its stories are about 30mins in length and are professionally edited and topically interesting. This month there was an interesting story published by The Daily from the NY Times on the Colonial Pipeline hack.
As a brief boiler plate: the Colonial Pipeline is a chain of Operational Technologies (OT) that provide gas from the Texas Gulf Coast through the Southeast and up to the Northeastern U.S. states (approx 5,500 miles). In June hackers attacked Colonial Pipeline with ransomware, crippling the supply chain and causing a panic buyout of gas across the eastern U.S.
This story was interesting in providing context to ransomware attacks: how these attacks initially manifested as attacks against individuals for paltry $100-$200 ransoms abroad, then to the U.S., and then expanded with North Korean WannaCry virus and Russian attacks against the Ukraine to target businesses. To quote the podcast:
But the legacy from that attack is that it really opened up cyber criminals’ eyes to just how vulnerable these American businesses, some of our most critical businesses, were to ransomware, and that these were really ripe targets
The contents of the podcast aren’t new (for those in InfoSec), but they are quite well put together. Its use of plain-language helps to orient the layperson on the dangers cyber security faces and paints a sobering image of what’s to come.
3. SCOTUS
A bit of a change of pace, I know. It’s not often I bring up the law-side of hacking. Oddly enough, a recent Supreme Court ruling weighed in on trying to more definitely consider what is (and what is not) hacking.
Earlier this month the Supreme Court of the United States ruled in Nathan Van Buren v. United States that the conviction of a Georgia Police Officer under the 1986 Computer Fraud and Abuse Act was not appropriate. The court rejected the government’s interpretation of the CFAA, which subjects to criminal liability anyone who “intentionally accesses a computer without authorization or exceeds authorized access”. What was at issue wasn’t whether or not Van Buren did something wrong (he used his patrol car computer to access information on a license plate in exchange for money), but whether his actions could be charged under the CFAA; in effect, as a police officer Van Buren was authorized to access the information, but was using it improperly.
There are a variety of implications that come from this ruling, but the most direct is that the meaning of “computer fraud” has been greatly narrowed.
4. Programming Project(s)
I was inspired recently to engage with my software development skills from 2 sources.
The first came from a common issue I’ve encountered in post-exploitation of UNIX-based targets. One of the common enumeration steps an attacker makes once they have a foothold on a system is checking installed binaries for the presence of the SUID bit being set. After dumping the list of binaries, I want to identify any that are known to have a privilege escalation vulnerability (a la GTFObins) and then - failing that - look for any unusual ones that aren’t commonly found. I’ve largely done this as either a manual process or leaning on less granular scanners (i.e. linPEAS.sh). My current vision is to have some script run on the attacker’s machine, ingesting the manual output from the target. We’ll see.
The second source of inspiration came from reading this Reddit AMA thread. The host was a Rapid7 Penetration Tester; among the many things discussed, one thing interesting that stood out to me was his suggestion to try writing/submitting your very own Metasploit module. This is appealing to me in several ways:
- It’s something new; I’ve never tried to develop a Metasploit module before.
- It’s feeding directly back into my professional development; I use Metasploit and I want to be a more technically-competent software developer.
- It’s in a language I’m not familiar with; Metasploit modules are written in Ruby, which would give me an opportunity to work with an entirely new language.
I’m thinking of taking one of my recently completed HackTheBox exploits and drafting a module off of that. We’ll see.
5. One Gadget
The last thing I wanted to share was a nifty tool I learned about while working through a PWN problem: one_gadget. This tool was a godsend when learning about Return-Oriented Programming (ROP) -based buffer overflows.
In a nutshell, I used the tool in order to identify the proper command to get to my executable code. There’s a whole lot more under the hood (some of which I still don’t understand), but without this I would have really struggled to get my payload to execute properly.