← All talks

NoSQL Means No Security?

BSides Athens · 202019:2489 viewsPublished 2020-06Watch on YouTube ↗
Speakers
Tags
CategoryTechnical
About this talk
Abstract: New systems are always interesting targets since their security model couldn’t mature yet. NoSQL databases are no exception and had some bad press about their security, but how does their protection actually look like? We will take a look at three widely used systems and their unique approaches:* MongoDB: Widely criticized for publicly accessible databases and a common victim of ransomware. Actually, it provides an elaborate authentication and authorization system, which we will cover from a historic perspective and put an emphasis on the current state.* Redis: Security through obscurity or how you can rename commands. And it features a unique tradeoff for binding to publicly accessible interfaces.* Elasticsearch: Groovy scripting has been a constant headache, but the new, custom-built scripting language Painless tries to take the pain away literally. Bio: Philipp lives to demo interesting technology. Having worked as a web, infrastructure, and database engineer for over ten years, Philipp is now working as a developer advocate at Elastic — the company behind the Elastic Stack consisting of Elasticsearch, Kibana, Beats, and Logstash. Based in Vienna, Austria, he is constantly traveling Europe and beyond to speak and discuss open source software, search, databases, infrastructure, and security. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Security BSides Athens 2020 CyberSecurity | InfoSec | Ethical Hacking | Computer Security | Evolving Threats | Threat Landscape | Privacy | Cyber Resilience Security BSides is a community-driven framework for building events by and for information security community members. These events are already happening in major cities all over the world! We are responsible for organizing an independent Security BSides-Approved event for Athens, Greece. More: https://www.bsidesath.gr Follow on Twitter: @BSidesAth
Show transcript [en]

hi and welcome to the next session I'm Philip let me share my screen and we'll jump right into it so let's go no sequel means no security is the topic of this session and by the way the question mark at the end is very important don't tell me afterwards that I said like there is no security in no secret because that would make my company very unhappy so just be clear this is a question mark and we want to dive into the question around that over the next 15 to 20 minutes or whatever we have so I work for elastic the company behind elastic search and various other pieces of software software and I want to give

you a bit of a broader picture about the no sequel ecosystem today so maybe you don't know TB engines comm it's a bit like the Tioga index for programming languages this one just the same thing for data stores and when you look at that you can see that the relational databases are still very much on top but you have one will be here is the top no sequel datastore in at least then you have plastic search readies and the recently Cassandra overtook Microsoft Access which shouldn't be in at least in the first place but for some reason it is and I will pick Mom will be ready and elastic search to dive into some security

concepts as we go a lot so let's jump into it everybody knows little poppy cables I guess for sequel injections and maybe don't call your children like drop table students or maybe do to figure out if people configured their system correctly and set it up correctly the nice thing about here or about this in no secret is if you don't have secret that means you don't have sequel injections right maybe it's not as simple we'll revisit the topic a couple of times and so let's jump into MongoDB and see what we can do there I'm just making fun of mummy because everybody does um now that they are public you can lose your data and your money with them

though admit they have been doing pretty well on the stock market and also like their consistency models and everything have improved a lot over time so let's not make fun of that but let's look at the security aspects so first off injections maybe you remember the ass brother wanna be Facebook killer or whatever from ten years ago so that was initially written in MongoDB and this is one of the code samples of what they had in there and this is a classic injection problem and since they don't have sequel they do support JavaScript instead so now you have a JavaScript injection so here when you just pass in a query and don't sanitize it and just run a random query which you

shouldn't really do and it's not really a best practice in MongoDB but you can then you kind of revisit the same issues that you had in the past and to have a couple of these functions which are prone to JavaScript injections like when you run an evil or you run the command in the MapReduce or you just run the where where you can provide JavaScript those are all vulnerable to injections so don't do that if you can avoid it and you can just disable JavaScript so if you know that you will never run JavaScript in your data store just disable the feature and you're done with it next up authentication which is kind of an interesting topic

so it's has been known for quite a long time and this is German and I'm sorry for the German but it basically says that some German University found 40,000 unsecured MongoDB data source on the internet more than five years ago and it took a while until people came from academia to the real world and figured out a way to make money out of that but then kind of like the ride was on so people then found out that you could rent some people for their data so electrically you download the data store it somewhere secure delete it on the server of whoever owns the data and just leave a note and say like hey if you

want to have your data back please pay here and we will give you back your data if they really have a the data and can return it is a different question but maybe they do and so this became quite a big sport which leads us to the questions or leads us to another example first here where somebody says like okay I found some data that is unsecured please give me a contact book where how we can secure that and then they'll stay okay but how did you get our contact details in the cell like well there was part of the open datastore that we found here so that leads us to the question is long

will it be binding to all interfaces like not just local host but all interfaces by default and no it is not anymore though it used to for quite a while so since three point six in 2017 so it took some time from people finding that and then mentioning it that was abled by for all the binaries that they put out so admittedly for the debian and RPM packages if i'm not mistaken that has been disabled for a much longer time so now every software that they release and every way that they package it it does only bind to local host anymore which is a good first step which leads us to the second question is

authentication enabled by default and it is not which is kind of unfortunate so you need to enable authentication true or captive or flag when you start the binary and they also have a slightly weird configuration dance when you set it up the first time you so you start the process first without authentication you add your user and only then can you login with that user that you had to create without authentication first but it is possible I guess they still don't have that enabled by default just to keep the bootstrapping problem or to set up as simple as possible which is especially important in the distributed system also TLS is now included or has been included for quite a long time in

pretty much any binary so this is the good stuff just remember don't run random scripts from users and enable authentication to make your life more secure which leads us to ready Stan and Redis has a couple interesting points so first of injections are totally thing as well and they even claim insecurity that well while they don't have JavaScript they have Louis critics that using Lua scripts from an untrustworthy storm source is a strange use case and probably many people agree but it's still something that will happen again and again also Salvatore the author who's an economist and theorist he had put out this blog post that a valid abbreviation of Lua scripts is a feature that should

be on by default he released that in June of 2018 and I think very soon after that people found several security issues in that that were then fixed which is slightly ironic but that's probably what you get when you have scripting in your datastore um coming to authentication Redis has a bit more of an interesting approach so a lot of the open various instances are infected by whatever kind of malware also partly brought deep because so matura has the very nice blog post showing how to actually crack and open Redis instance and in his opinion he wants to share that because the bad people will figure that out anyway and he just wants to educate anybody how easy it is to

actually break into the server if you have an open various instance running and it goes into quite a lot of detail in his plot as well those rate is fine to all interfaces it does but with a twist so what is the twist and they have something called protected mode so if you run the query locally it will just run the query and answer that in the default settings but if you query it remotely we will just respond with an error and say like well remote queries you need to enable that explicitly either in the configuration or you need to set up security which probably would make more sense but by default it will only answer queries on localhost and

give you a proper error message from remote so they picked this just approach of not just finding two locals but rather opening up to external interfaces to give you a better error message and this has been around for quite a while security was otherwise on 6.0 came out quite recently and 6.0 changed a lot in terms of security so before that version their documentation claimed a tiny layer of indicate authentication that is optionally turned on is what they provide and there was no authorization building so what you basically got was you had one password that you could use with AWS password and then run whatever command you wanted that password was stored in plain text

in the Redis configuration file and there was no built-in TLS or rate-limiting so you would have to run your own proxy in front to for example terminate TLS and the good or bad thing about Redis is that it's very fast and since there is no rate limiting if you can run lots of requests against it you can also try to brute-force passwords very quickly so pretty very good password here otherwise that will probably be not helping you out too much but since 6-0 which came out bit earlier this year things have tightened down quite a bit so now you have access control lists where you can whitelist commands or you can wipe this specific key spaces and now you have multiple

users and you can run authentication for the user with password also you can while you can still store credentials in plaintext in the red configuration file you can alternatively and it's either this word the other use or store the sha-256 hash in NaCl conf to actually store that and you can enable and TLS in the build now so Redis also has TLS support built-in so a lot of stuff has improved one final interesting feature of Redis is that you can hide commands and that was especially useful before the ACL world where so before six when you could disable specific features what you would do before then is dangerous command you could just rename so what that looks

like is in the Redis configuration file you would store this and to reset or change that you would need to restart the server but would you what you could do is let's say you want to rename the command config and you run this rename command command with config and then my secret config name so basically to run confid you could only access it if you know that it has to be called my secret country game so basically you would need to know what did you rename a command to actually be able to use it and some people used hashing with the salt to actually just then use that hash to access commands that they had been

hiding before and not explicitly rename it to some other command what you could also do is you could disable a command entirely by saying rename command conflict and then give it an empty name so there is nothing in between the quotations here so that command would just be disabled and you couldn't access it at all this was a global configuration and one of the more intriguing security aspect or approaches I would say finally elasticsearch so does it bind to all interfaces not anymore for a long time so we stopped that into zero which came out like I want to say six years ago or five years ago or something like that and so it has

only been binding to localhost for a long time security has become free a year ago or so before that was one of the key features though since ask such speeds HTTP you could very easily protect that with an HTTP reverse proxy like nginx for example and also terminate TLS but a year ago those features also because of kubernetes became free because there is no easy security model in communities for example is authentication enabled by default not yet maybe we can get to that in the next major version but you can see since we only added that in 7.1 and not 7.0 it would have been a breaking change so we didn't enable by default yet so 8.0 will be the next

chance where we might be able to do that though that's still a bit off so we don't really know yet and scripting is one of the interesting approaches here if you look at the bad security issues that elasticsearch had in the past a lot were related to scripting like we relied heavily on groovy then every now and then somebody would find some way to break out of the groovy sandbox and could then potentially take over elasticsearch nodes and we had a lot of the really bad security issues where because of that so we create their own scripting language which is called painless which might not be the perfect name because people find it pretty painful every now and then we hire the

developer to actually write and create that it took quite some time to write and then people often ask like why do you even create your own scripting language when there are so many out there basically because we wanted to have two attributes and those are security and performance and painless has been out for a couple of years now and I'm not really aware of any security issues we had with that so at least from the security perspective it worked and also performance is much better than Ruby because of the way we can store the bytecode so it was just custom-built for this specific use case and while you don't have to allow lists in the first place

what you want to have okay and in a later version then this came out in 5-0 if I remember correctly in the red next major version the other scripting languages were removed and since then we don't have any security issues around those anymore luckily ransoming is still an interesting problems so every now and then you can just look on Sudan for open elasticsearch data source so here I look for a default port which is 9200 anything that responds with the 200 okay is potentially an elasticsearch instance like this one here and if you query one of these instances then you can just check by which in the sense of more less tables are there and then you might have

one that says for example is read and then when you look at that and you will potentially find something like this and you have this nice message here which says well if you want to have your data back send 0.5 Bitcoin or that fluctuated because of their fluctuating price of Bitcoin so send some whatever bitcoin here and we might be able to give you back your data and if all of those instances that you will find today are honey pots or how many contain real either is it up for debate but open elasticsearch instances are unfortunately more common that we would then we would want it to be and yeah depending on the Bitcoin price 0.5 might

be pretty expensive one not so expensive and I think at some point when there was this extreme hype around Bitcoin they would just say like whatever is a thousand dollars today just sin send us the equivalent in Bitcoin because if they left the message and five days like the price might have tripled already so to avoid that they at some point switch to dollar equivalent but I think now Bitcoin is a bit more stable again and maybe they can stick to record prices and finally sometimes you might run into the so-called matroyshka problem or I call it the math rush the problem that somebody takes your data and leaves a message the data store is still open

so somebody else comes takes that message and leaves their own message and to get back to the person that has your data initially you would need to go from like one hot rush cut to the next to get back to the original person who has your data which you probably don't want to do but yeah and we ourselves ran some open data stores every now and then and for example in Germany the German search would just scan German IP addresses and then send you met warning messages through your provider to please fix that because this is a very unsecure set up and you definitely don't want to have that and you don't want to rely on the

search to be faster to find your open elasticsearch instances then the bad guy is finding them so just don't run open data stores and so to wrap up injections are still a thing and while it doesn't have to be sequel it could be javascript or lure or groovy or whatever you have that you don't tighten down and it was security hopefully the data stores will do that by default like the relational databases had a bit more time to learn the lesson and they do that by default now I hope the no sequel data stores will get there soon as well d creative lag red is slight with the protected mode and disabling or renaming commands or maybe

not I'm still unsure if that is very creative and interesting or just like kind of like not the proper solution so you should find a proper solution but it's definitely interesting custom scripting can make sense in terms of security especially when you don't want to put various functions like reflection or so on and disallow this or denialist and security unfortunately takes time so since relational database has had more time to mature they generally do a bit better than a no sequel later sort but the no sequel data stores are catching up and I hope we will have like everything like here less this available authentication authorization are available and will be enabled by default I hope that we reach that stage soon

enough and the ransomware attacks will become more an uncommon sighting of the past more than a common occurrence which it is unfortunately still and that let's head to the questions thanks so much for listening