DOGE left their database unprotected
For a time, you could freely push updates to the group's homepage. And some people did!
Programming note: I had COVID for the past week. I am better and I am back to my regular schedule!
DOGE has been in the news quite a lot recently. I’ll leave the more obvious criticisms to people who are better at making them, and zero in on something that a software engineer is qualified to talk about: they got their site defaced because of bad software engineering practices.
Anyone Can Push Updates to the DOGE.gov Website
Two different web development experts who asked to remain anonymous because they were probing a federal website told 404 Media that doge.gov is seemingly built on a Cloudflare Pages site that is not currently hosted on government servers. The database it is pulling from can be and has been written to by third parties, and will show up on the live website.
Both sources told 404 Media that they noticed Doge.gov is pulling from a Cloudflare Pages website, where the code that runs it is actually deployed.
One of the sources told 404 Media that they were able to push updates to a database of government employment information after studying the website’s architecture and finding the database’s API endpoints.
If you’re not familiar with Cloudflare Pages, it’s effectively their JAMStack entrant. It has a few pieces: it’s basically a way to define static sites, and also allows you to define server-side service workers that run on Cloudflare’s network for APIs and dynamic content1. The implication here is that one of the service worker API endpoints was unauthenticated and did not have authorization built in.
How did this happen? Anyone who has been in the industry long enough will probably guess the same reason: a bunch of people self-organized and started Moving Fast and Breaking Things, and either the code wasn’t reviewed or it was reviewed by someone who wasn’t qualified to give it the thumbs up2.
ProPublica has been identifying DOGE employees. Some college-age employees have gotten all of the headlines, but there are plenty of experienced software engineers working on the effort. They surely know that it’s bad when someone tells you, “You have an API endpoint that writes to a database and has no authorization or authentication.” What is the implication? Someone will eventually map out your API, either by decompiling your client or by sniffing traffic to your server. They never did that for your side project or your student project? Well, those projects were not the frontpage for the hottest new website on the .gov domain3.
If they weren’t powering an official government experience, I supposed I’d have some sympathy for the younger engineers in this group? Imagine that you’re just getting started in the industry, and you’re learning about all of the security principles that you need to be reasonably secure.
Are you running your own machine? You’ll need to harden it obviously. You should disable or minimize SSH access. You should use a firewall to block off every port and protocol except the bare minimum. Your application should be running with minimal permissions. Make sure to apply every security update going forward!
Does your service have privileged operations? User accounts that should not interfere with each other or different accounts with differing levels of privilege? Then you should build authentication and authorization. Take care that passwords use an appropriate algorithm to make them resistant to brute-force attacks. And always be sure to add proper authentication and authorization everywhere.
Does your code need a third-party client like a web browser or an app? Well, then you need to set up TLS certificates with a service like Let’s Encrypt. Definitely use a framework or library with built-in security considerations like escaping all input that goes into a database. Then you have an entire host of web attacks that you should strive to avoid, like XSS, clickjacking, content spoofing, etc.
Are you running it on infrastructure like AWS? Are you using any third-party services?If so, ensure that traffic between your services aren’t routed over the open internet, otherwise you should encrypt the traffic between the machines so that other people can’t snoop on it.
And on any nontrivial site, you’ll still run into a bunch of weird problems. This is also a partial list of security problems you could encounter. If you were building to protect against state-sponsored attackers, you would surely want to follow a happy path of keeping your site secure and safe.
Now let’s look at this from an EFFICIENCY perspective. If you were truly concerned about government efficiency, you would surely use resources already at your disposal. For example, USDS has been dragging the government’s digital footprint out of the stone age since the Obama years, and they know better than anyone how to run any kind of site. Just demand that a high-ranking employee in USDS meet with your programmers. Just make their highest-ranking techie (let’s call them a CTO) show up. And that CTO would surely, in the course of a 1 hour consultation, tell them, “you’re overcomplicating this. You don’t need to talk to a database, your site can just be completely static. You don’t need to interface with figuring out how to run stuff on government servers, you don’t need to set up a database, ::DOGE engineer corrects them and says they’re running on Cloudflare Pages:: oh Jesus, anyways you don’t need to set up Cloudflare pages, you don’t need to waste two days figuring out why something can’t talk to something else. You could launch this today if your site just has a couple of pages. You can literally use our own homepage as a template. Clone it right now if you’d like!”
But this whole exercise isn’t about efficiency, is it?
And vendor lock in, most likely.
My hunch is that it was never reviewed.
DOGE is lucky that the first attackers didn’t send the entire script to the Bee Movie down that API call.