Adding docker containerization for mongo, plus footgun link (thx @tedder42)

This commit is contained in:
Samuel Clay 2021-06-28 20:00:42 -04:00
parent 159251f3c0
commit 3c48611006
4 changed files with 9 additions and 9 deletions

View file

@ -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.

View file

@ -135,13 +135,13 @@
<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 wouldnt do anything because the vandals dont 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 MongoDBs 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 NewsBlurs 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 didnt 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 didnt 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, Im a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlurs 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>

View file

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.2.0">Jekyll</generator><link href="https://blog.newsblur.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.newsblur.com/" rel="alternate" type="text/html" /><updated>2021-06-28T18:50:18-04:00</updated><id>https://blog.newsblur.com/feed.xml</id><title type="html">The NewsBlur Blog</title><subtitle>NewsBlur is a personal news reader that brings people together to talk about the world.
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.2.0">Jekyll</generator><link href="https://blog.newsblur.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.newsblur.com/" rel="alternate" type="text/html" /><updated>2021-06-28T20:00:13-04:00</updated><id>https://blog.newsblur.com/feed.xml</id><title type="html">The NewsBlur Blog</title><subtitle>NewsBlur is a personal news reader that brings people together to talk about the world.
A new sound of an old instrument.
</subtitle><entry><title type="html">How a Docker footgun led to a vandal deleting NewsBlurs MongoDB database</title><link href="https://blog.newsblur.com/2021/06/28/story-of-a-hacking/" rel="alternate" type="text/html" title="How a Docker footgun led to a vandal deleting NewsBlurs MongoDB database" /><published>2021-06-28T00:00:00-04:00</published><updated>2021-06-28T00:00:00-04:00</updated><id>https://blog.newsblur.com/2021/06/28/story-of-a-hacking</id><content type="html" xml:base="https://blog.newsblur.com/2021/06/28/story-of-a-hacking/">&lt;p&gt;&lt;em&gt;tl;dr: A vandal deleted NewsBlurs MongoDB database during a migration. No data was stolen or lost.&lt;/em&gt;&lt;/p&gt;
@ -65,13 +65,13 @@ A new sound of an old instrument.
&lt;p&gt;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 wouldnt do anything because the vandals dont have the data and have nothing to release.&lt;/p&gt;
&lt;p&gt;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 MongoDBs server connection.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;While the server was being snapshot, I used that time to figure out how the hacker got in.&lt;/p&gt;
&lt;h3 id=&quot;2-how-did-newsblurs-mongodb-server-get-hacked&quot;&gt;2. How did NewsBlurs MongoDB server get hacked?&lt;/h3&gt;
&lt;p&gt;Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didnt 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 &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;sudo iptables -L | grep 27017&lt;/code&gt; showed that MongoDB was open the world.&lt;/p&gt;
&lt;p&gt;Turns out the ufw firewall I enabled and diligently kept on a strict allowlist with only my internal servers didnt 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 &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;sudo iptables -L | grep 27017&lt;/code&gt; showed that MongoDB was open the world. This has been &lt;a href=&quot;https://github.com/moby/moby/issues/4737&quot;&gt;a Docker footgun since 2014&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;To be honest, Im a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlurs 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.&lt;/p&gt;

View file

@ -132,13 +132,13 @@
<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 wouldnt do anything because the vandals dont 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 MongoDBs 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 NewsBlurs 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 didnt 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 didnt 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, Im a bit surprised it took over 3 hours from when I flipped the switch to when a hacker/vandal dropped NewsBlurs 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>