From 3c4861100662a2510ae3c6ee5aaaab9e93b5fd76 Mon Sep 17 00:00:00 2001 From: Samuel Clay Date: Mon, 28 Jun 2021 20:00:42 -0400 Subject: [PATCH] Adding docker containerization for mongo, plus footgun link (thx @tedder42) --- blog/_posts/2021-06-28-story-of-a-hacking.md | 4 ++-- blog/_site/2021/06/28/story-of-a-hacking/index.html | 4 ++-- blog/_site/feed.xml | 6 +++--- blog/_site/index.html | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/blog/_posts/2021-06-28-story-of-a-hacking.md b/blog/_posts/2021-06-28-story-of-a-hacking.md index c6b15d88c..1fce6676e 100644 --- a/blog/_posts/2021-06-28-story-of-a-hacking.md +++ b/blog/_posts/2021-06-28-story-of-a-hacking.md @@ -64,13 +64,13 @@ The most important bit of information the above chart shows us is what a full da This tells us that the hacker was an automated digital vandal rather than a concerted hacking attempt. And if we were to pay the ransom, it wouldn't do anything because the vandals don't have the data and have nothing to release. -We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB. Unless the attacker had access to a 0-day, it is highly unlikely they were able to break out of MongoDB's server connection. +We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB in a Docker container. Unless the attacker had access to a 0-day to both MongoDB and Docker, it is highly unlikely they were able to break out of the MongoDB server connection. While the server was being snapshot, I used that time to figure out how the hacker got in. ### 2. How did NewsBlur's MongoDB server get hacked? -Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn't work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was "active", doing a `sudo iptables -L | grep 27017` showed that MongoDB was open the world. +Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn't work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was "active", doing a `sudo iptables -L | grep 27017` showed that MongoDB was open the world. This has been [a Docker footgun since 2014](https://github.com/moby/moby/issues/4737). To be honest, I'm a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlur's MongoDB collections and pretended to ransom about 250GB of data. This is the work of an automated hack and one that I was prepared for. NewsBlur was back online a few hours later once the backups were restored and the Docker-made hole was patched. diff --git a/blog/_site/2021/06/28/story-of-a-hacking/index.html b/blog/_site/2021/06/28/story-of-a-hacking/index.html index 4a0f21ce7..07ab657b2 100644 --- a/blog/_site/2021/06/28/story-of-a-hacking/index.html +++ b/blog/_site/2021/06/28/story-of-a-hacking/index.html @@ -135,13 +135,13 @@

This tells us that the hacker was an automated digital vandal rather than a concerted hacking attempt. And if we were to pay the ransom, it wouldn’t do anything because the vandals don’t have the data and have nothing to release.

-

We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB. Unless the attacker had access to a 0-day, it is highly unlikely they were able to break out of MongoDB’s server connection.

+

We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB in a Docker container. Unless the attacker had access to a 0-day to both MongoDB and Docker, it is highly unlikely they were able to break out of the MongoDB server connection.

While the server was being snapshot, I used that time to figure out how the hacker got in.

2. How did NewsBlur’s MongoDB server get hacked?

-

Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn’t work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was “active”, doing a sudo iptables -L | grep 27017 showed that MongoDB was open the world.

+

Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn’t work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was “active”, doing a sudo iptables -L | grep 27017 showed that MongoDB was open the world. This has been a Docker footgun since 2014.

To be honest, I’m a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlur’s MongoDB collections and pretended to ransom about 250GB of data. This is the work of an automated hack and one that I was prepared for. NewsBlur was back online a few hours later once the backups were restored and the Docker-made hole was patched.

diff --git a/blog/_site/feed.xml b/blog/_site/feed.xml index 92ca0c99b..757346eb1 100644 --- a/blog/_site/feed.xml +++ b/blog/_site/feed.xml @@ -1,4 +1,4 @@ -Jekyll2021-06-28T18:50:18-04:00https://blog.newsblur.com/feed.xmlThe NewsBlur BlogNewsBlur is a personal news reader that brings people together to talk about the world. +Jekyll2021-06-28T20:00:13-04:00https://blog.newsblur.com/feed.xmlThe NewsBlur BlogNewsBlur is a personal news reader that brings people together to talk about the world. A new sound of an old instrument. How a Docker footgun led to a vandal deleting NewsBlur’s MongoDB database2021-06-28T00:00:00-04:002021-06-28T00:00:00-04:00https://blog.newsblur.com/2021/06/28/story-of-a-hacking<p><em>tl;dr: A vandal deleted NewsBlur’s MongoDB database during a migration. No data was stolen or lost.</em></p> @@ -65,13 +65,13 @@ A new sound of an old instrument. <p>This tells us that the hacker was an automated digital vandal rather than a concerted hacking attempt. And if we were to pay the ransom, it wouldn’t do anything because the vandals don’t have the data and have nothing to release.</p> -<p>We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB. Unless the attacker had access to a 0-day, it is highly unlikely they were able to break out of MongoDB’s server connection.</p> +<p>We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB in a Docker container. Unless the attacker had access to a 0-day to both MongoDB and Docker, it is highly unlikely they were able to break out of the MongoDB server connection.</p> <p>While the server was being snapshot, I used that time to figure out how the hacker got in.</p> <h3 id="2-how-did-newsblurs-mongodb-server-get-hacked">2. How did NewsBlur’s MongoDB server get hacked?</h3> -<p>Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn’t work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was “active”, doing a <code class="language-plaintext highlighter-rouge">sudo iptables -L | grep 27017</code> showed that MongoDB was open the world.</p> +<p>Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn’t work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was “active”, doing a <code class="language-plaintext highlighter-rouge">sudo iptables -L | grep 27017</code> showed that MongoDB was open the world. This has been <a href="https://github.com/moby/moby/issues/4737">a Docker footgun since 2014</a>.</p> <p>To be honest, I’m a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlur’s MongoDB collections and pretended to ransom about 250GB of data. This is the work of an automated hack and one that I was prepared for. NewsBlur was back online a few hours later once the backups were restored and the Docker-made hole was patched.</p> diff --git a/blog/_site/index.html b/blog/_site/index.html index 739e99a68..e6a734bcc 100644 --- a/blog/_site/index.html +++ b/blog/_site/index.html @@ -132,13 +132,13 @@

This tells us that the hacker was an automated digital vandal rather than a concerted hacking attempt. And if we were to pay the ransom, it wouldn’t do anything because the vandals don’t have the data and have nothing to release.

-

We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB. Unless the attacker had access to a 0-day, it is highly unlikely they were able to break out of MongoDB’s server connection.

+

We can also reason that the vandal was not able to access any files that were on the server outside of MongoDB due to using a recent version of MongoDB in a Docker container. Unless the attacker had access to a 0-day to both MongoDB and Docker, it is highly unlikely they were able to break out of the MongoDB server connection.

While the server was being snapshot, I used that time to figure out how the hacker got in.

2. How did NewsBlur’s MongoDB server get hacked?

-

Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn’t work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was “active”, doing a sudo iptables -L | grep 27017 showed that MongoDB was open the world.

+

Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didn’t work on a new server because of Docker. When I containerized MongoDB, Docker helpfully inserted an allow rule into iptables, opening up MongoDB to the world. So while my firewall was “active”, doing a sudo iptables -L | grep 27017 showed that MongoDB was open the world. This has been a Docker footgun since 2014.

To be honest, I’m a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlur’s MongoDB collections and pretended to ransom about 250GB of data. This is the work of an automated hack and one that I was prepared for. NewsBlur was back online a few hours later once the backups were restored and the Docker-made hole was patched.