On a whim, I recently migrated all of my Git repositories to a cgit instance on WIREDNET. It's caused some headaches because the server-side rendering can be quite resource intensive. Mere minutes after setting it up, the fans on my server spun up because the repos were being scraped by ClaudeBot and friends. I hadn't linked to it from anywhere, so it's likely they found it from LetsEncrypt's issuance logs. It was easy enough to mitigate the scraping by putting a robots.txt up, and I was able to forget about it for a month or so, until I was sitting at work and got an alert from Gatus that several of my services were down. I checked the logs and saw that Apache was being hammered by 47.76.0.0/14 (no name provided) and 47.80.0.0/13 (Alibaba Cloud LLC), which I blocked at the firewall level. This was enough to mitigate the attack, but I was still seeing an unusual amount of traffic in my Apache logs. cgit was, once again, being aggressively scraped. Most of my repositories are small, but I had a mirror of Guix from when I was doing GSOC, and forks of a few other popular repositories, and the crawlers were just going through every single link generated by cgit (basically encompassing the entire source tree for every single commit in the repository). I was reminded of Konstantin Ryabitsev's blog post "Creepy Crawlies", which contains this helpful piece of intuition: "if [an IP is] asking for an old commit in a random old fork, it's probably not a real developer trying to do their work." I don't see any reason that someone would be looking that far into a Guix mirror that's several years out of date, so I wrote a fail2ban rule.
read more →
Well, this is certainly overdue. It's the writeup for a challenge I authored for
this year's UMass CTF, which ran from October 5th to October 12th. Yes, I'm
late. But when you attend a university that tried very hard to squeeze the
entire semester twelve weeks, you're going to deal with burnout and not nearly
enough time to do things outside of your coursework. So I'm finally coming back
to the challenge now that the semester's ended.
read more →
It's typical for the younger sibling to look up to and mimic the older sibling,
which is apparently what happened while I was away at school. I'm self-hosting a
few services off of a Raspberry Pi B+ back at my parents' house, and when my
brother got a Pi of his own, he decided that he also wanted to use it for
self-hosting. Unfortunately, he doesn't know much about security, and
unintentionally did me the favor of setting up a honeypot.
read more →
My long-lived hiatus from capture-the-flag has come to an end, as I got off my
ass this weekend to play in PlaidCTF 2019. Being a one-man team is pretty
lonely, but my old team wasn't playing, and even if they were, I don't know if I
would've wanted to make the commute just to play with them.
read more →
TL;DR, I discovered a stack-smashing vulnerability in GZDoom's interpreter for
ACS. As a preface, there's a tendency for whitepapers like this in the security
community to be written with a somewhat condescending tone towards the product's
vendor. I do not mean for any portion of this writeup to come off as degrading
to the developers involved. Yes, the bug was obvious to me, but it was still
subtle enough that it went under the radar for nearly 23 years. Most developers
aren't actively thinking about this kind of attack while writing a bytecode
interpreter. I have an enormous amount of respect for the development teams of
both GZDoom and Zandronum, who were quick to issue a patch addressing the issue
and were respectful of my wishes to release this whitepaper to the public. I'd
also like to thank everyone I had the pleasure of working with during this
process; it warms my heart to know that the communities behind these open-source
software projects are this friendly.
read more →
"funsignals" was a 250 point binary exploitation challenge with 58 solves. The
challenge itself was a very trivial example of sigreturn-oriented programming.
read more →