This is the first post in a three-part retrospective on teaching CS 40.

Last quarter (Winter 2024), Cody Ho and I taught CS 40 Cloud Infrastructure and Scalable Application Deployment at Stanford, a new course we’d been working on creating for nearly a year. CS 40 is Stanford’s first-ever hands-on intro cloud computing course, and with 50 students enrolled, achieving our instructional goals of leaving students with a robust understanding of the material was no easy feat.

Wrapping up the quarter, I’m thrilled with how the course turned out, even given how hectic it was at times. This post is a retrospective on the process of designing the course, getting it approved, and building out course content before the start of the quarter.

I acquired my personal domain saligrama.io in August 2018, and since then, I’ve used a number of different providers to manage its DNS records as well as the hosting infrastructure hanging off of it.

Recently, I decided to migrate as much of this infrastructure as I could to Cloudflare. This post describes the migration process that enabled me to move everything over smoothly without any downtime, all while using Terraform to systematize the resources with infrastructure-as-code.

Ever since I started exploring security more deeply, I’ve been asked countless times by people if I could hack into grading systems to change my (or, more often, their) grades. With Gradescope being the most ubiquitous platform for grading STEM classes at Stanford, my standard response was always that I couldn’t, imagining that a well-established EdTech company would secure their platform well enough.

As it turns out, Gradescope’s autograders have been vulnerable to various types of attack since 2016. Gradescope has known about the issues since at least 2020, yet has indicated it cannot distribute a general fix.

This post covers my exploration of Gradescope’s autograder vulnerabilities, an analysis of the potential impact on courses, and how I created Securescope, my attempt at a more secure autograder configuration.

In my last post, I covered the marvelous world of Firebase database spelunking: when app developers misconfigure their Firestore security rules, the resulting ability to perform unauthorized data accesses can lead to terrifying data breaches for those apps. Thanks to tools like Baserunner, testing apps for such misconfigurations is easier than ever.

By saving authorization state when logging into Firebase databases using email/password or phone/OTP sign-in methods, Baserunner lets you focus on actually querying the database for data. However, what happens when client apps only allow sign-in using a Google account?

This blog post covers how Glen Husman and I conducted security testing of such a Firebase client app, using a clever solution to grab the Google OAuth token to sign into the database with. I then used lessons learned from that engagement to contribute Google sign-in functionality back to Baserunner.

By shifting the data authorization and access restriction burden from robust programmatic systems running on a server to static security rules, backend-as-a-service platforms like Google Firebase put new app developers and their products at risk of catastrophic data breaches if utmost care is not paid to the efficacy of these rules.

This blog post details how to find such vulnerabilities in apps using Firebase as a backend. I also tell the story of one such vulnerability I found (along with Miles McCain and Cooper de Nicola) in Fizz, a popular anonymous posting platform at Stanford and other universities. Fizz’s improper handling of Firebase security rules allowed full deanonymization of all posts down to email and/or phone number and unauthorized granting of moderator permissions.

Lastly, I talk about legal threats we received in the course of disclosing these vulnerabilities.

This morning, an EternalBlue-vulnerable machine used for testing for Stanford’s Hack Lab course accidentally given a public IP address on Google Cloud was unsurprisingly pwned and used to launch further EternalBlue scanning against other public web hosts.

This blog post describes our course’s infrastructure setup (including why we had that testing box in the first place), how we discovered and remediated the incident, and how we used the incident as a way to teach students about incident response and public disclosure.

This is a continuation of my previous post about upgrading personal security. This post focuses on preventing evil maid attacks using disk encryption and secure boot.

With this post, I compiled and summarized all of the resources I used to do all of this configuration. The hope is that having a set of steps in one place reduces the need to go hunting across different Reddit posts, blog posts, and wiki articles as I did.

I’m someone who’s been reasonably technical for a long time, but was not really interested in security until about a year and a half ago. This means I had a lot of configuration set up for convenience, but without much in the way of security.

In the last few weeks, I started to change that and significantly upgraded my personal security. This post covers the first steps I took towards that end, starting with password generation and better two-factor authentication.

Hello, world!

Test post for this blog.