1

I have recently set up parse-server on a DO VPS using 3 docker containers; one for parse-server, one for parse-server dashboard and one for mongodb. Because I am just testing this setup I left the mongo container as it is: mongodb://mongo:27017/dev.

I have NGINX (not in docker) running as a reverse proxy (to get SSL). It forwards port 80 and 443 to http://127.0.0.1:4040 internal (the parse dashboard web gui). and it routes 1338 to http://127.0.0.1:1337 the parse server (API) itself. This parse server connects to my mongo DB internally.

This is the first time I am using Docker and MongoDB.

Because of this setup and the mongo db port not open I thought it would be half-decently safe.

How did the hacker breach my database? There was nothing of value stored but there might be in the future. I don't think he exploited my parse server because I could see the connection coming from a cpython client (the parse connection showed as nodeJS client.

I have added: NGINX, FIREWALL,Docker processes, Mongo LOG lines

nginx terminal

{"t":{"$date":"2020-08-13T12:23:14.165+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"connection accepted","attr":{"remote":"46.182.106.190:39672","sessionId":31,"connectionCount":3}}
{"t":{"$date":"2020-08-13T12:23:14.359+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn31","msg":"client metadata","attr":{"remote":"46.182.106.190:39672","client":"conn31","doc":{"driver":{"name":"PyMong                      o","version":"3.10.1"},"os":{"type":"Linux","name":"Linux","architecture":"x86_64","version":"4.15.0-112-generic"},"platform":"CPython 3.6.9.final.0"}}}
{"t":{"$date":"2020-08-13T12:23:15.941+00:00"},"s":"I",  "c":"COMMAND",  "id":20337,   "ctx":"conn31","msg":"dropDatabase - starting","attr":{"db":"READ_ME_TO_RECOVER_YOUR_DATA"}}

> db.README.find();
{ "_id" : ObjectId("5f3536cd2a546e2eea8211eb"), "content" : "All your data is a backed up. You must pay 0.015 BTC to 145Nny3Gi6nWVBz45Gv9SqxFaj                                                                                              uwTb2qTw 48 hours for recover it. After 48 hours expiration we will leaked and exposed all your data. In case of refusal to pay, we will contac                                                                                              t the General Data Protection Regulation, GDPR and notify them that you store user data in an open form and is not safe. Under the rules of the                                                                                               law, you face a heavy fine or arrest and your base dump will be dropped from our server! You can buy bitcoin here, does not take much time to                                                                                               buy https://localbitcoins.com with this guide https://localbitcoins.com/guides/how-to-buy-bitcoins After paying write to me in the mail with yo                                                                                              ur DB IP: restore_base@tuta.io" }
Improve this question
4
  • 1
    It is unclear how the hacker breached your database solely based on your information. But given that the DB could not be accessed from outside the attacker obviously accessed it from inside. How the local access was gained is unknown, but it might be a weak SSH password, bug in the web application or whatever.
    – Steffen Ullrich
    Aug 13, 2020 at 14:38
  • Daniel, the formatting made it unreadable. Steffen, you can find a article online that says 50k databases are affected, but can't find out anywhere what the vulnerability is. Can't imagine it is through SSH since it would make more sense then to encrypt the disk
    – userRR
    Aug 13, 2020 at 22:15
  • "... you can find a article online that says 50k databases are affected, but can't find out anywhere what the vulnerability is" - I don't know which articles you refer to but the articles I read about the topic explicitly talk about internet-facing instances. You specifically say that your instance is not reachable from the internet though.
    – Steffen Ullrich
    Aug 14, 2020 at 4:39
  • Steffen, I just did a deeper look, downloaded nmap and dit a port scan on my VPS, it came back with the default port for mongoDB open.. That is pretty strange since I never opened it in my firewall.. this must be some witchfraft from the docker engine?
    – userRR
    Aug 14, 2020 at 11:24

1 Answer 1

Reset to default
3

Exposing a port through Docker bypasses ufw because Docker directly creates an iptables rule. So your firewall is useless.

You do not actually need to expose the container port to the host, however, in order to enable other containers to access it. I recommend simply not exposing your ports except if they need to be accessed externally.

Improve this answer
1
  • I agree on this, but there are firewalls I believe acting on different layers I believe. Although mine bypassed ufw, I closed the port again with my cloud provider offered firewall (ovh). I have been hacked in the same way stated above.
    – Abderrahim ben
    Jul 18, 2022 at 6:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .