 Okay thank you everybody for coming or staying so this talk is going to be about no sequel no injections my name is Wayne Hwang I am co-founder and CTO to Amarai Technologies and my colleague Kuang Ding was a founding member he was the first person to our Amarai Special Force team more than four years ago this research was mostly done by Kuang while I am the I will be the presenter because I speak better English most of Amarai's are based out of Taipei and we're all from Taiwan so the research this research started when we were crawling when we were crawling so much of the web to identify malware and we had to ourselves implement a no sequel solution and basically just retire our own relational database solution so Amarai has two teams one is on static analysis so we do we write parsers and compilers and we check for vulnerabilities inside code so actually this is more related to that team but this research actually started from the other team crawling the web in search for malware and because the data was getting much too big for traditional relational databases to handle so that team the hackler team started to do this research but then this research would then actually benefit the code secure team because as we see more and more see no sequel code we need to know how to scan for vulnerabilities inside that code and this is how the talk came about so the slides are on slides here now and if you go to my Twitter you would get the link to the three of our talks this year at DEF CON the next talks is gonna be tomorrow it's about how we automatically cluster the malware that we find using OBOX so today we're gonna be talking about what is no sequel types of no sequel who uses no sequel and so where the threats are note the no sequel architecture security issues surrounding no sequel and different families of no sequel and prevention and detection and how no sequel is affecting the current security technologies so what is no sequel no sequel technologies do not come some common misconceptions no sequel technologies do not support sequel the fact is a lot of them do no sequel technologies are not vulnerable to threats such as sequel injection because there's no sequel one of the most commonly accepted definitions would be no sequel is not only a sequel and the storage itself is a non-relational DBMS which can be semi-structured and schema less or sometimes perhaps even schema free for example in a key value data store so types of no sequel there are a lot of families to no sequel key value that key value based databases column based databases document based databases graph based databases object based databases etc so what's challenging for security researchers today is no sequel is resembled by its diversity there are a lot of families and then within the same family of no sequel implementations differ widely and that presents a very big challenge as we see it so why no sequel why do people need to use the no sequel technology well mostly for two very important reasons performance and scalability so who would use no sequel and so what's the impact cloud computing users or providers or SaaS vendors social network services providers portal websites and basically people that needs to process large amounts of data and typically they would use a mixture of databases which include both sequel databases and no sequel databases and that is for example what what our current implementation is as well so what's changed from the past from sequel to no sequel so here's a typical no sequel architecture we have the web application and web services in the front and in the center is the client library which the web application and web services interact with and then below is the no sequel data storage and the client library is going to be the focus for security researchers as well as the attackers because that's where the web application web services are interfacing with the data storage so the client library implementation right now has no standards such as odbc jdbc ado pdo etc so these questions would strongly affect the security standing and aspects of these client libraries how is it implemented what interface is this is support does it support the query interface and here you see a couch db sorry a couch db implementation of its sequel interface oh I'm sorry couch ql and actually as you can see it looks very much like sequel and in fact it is a subset of sequel my couch db it itself is a no sequel database and so here this how this client library is implemented will affect what types of vulnerabilities would exist in this particular implementation and so let's make room and let's look for let's look at the old vectors versus the new vectors so in the old days there was only one horizontal vector the sequel right and so within that horizon you would have we would have odbc jdbc ado pdo what have you for us and for or for the attackers to do their sequel injections now we have key value based databases and they may implement two versions at least two versions of their client libraries the ql like and the non ql like and these two different versions would have a lot of different implementations and the same thing would be happening to column based no sequel databases and the same thing happens to document based no sequel databases so let's make room same thing happens to graph based no sequel databases and the same thing happens to object based no sequel databases so this is the landscape as we see it today so as a vendor that that developed static analysis tools to scan for security vulnerabilities before we for for for example for database manipulation for command injection we had to scan for only a few categories and sequel injection was among these categories but now if we want to support if we want to scan for no sequel vulnerabilities weigh in up with a landscape that looks like that down there so perhaps it was a blessing that in the past the notion of rdbms matured the notion of sequel matured and sequel implementation standards matured as well odbc jdbc etc and therefore as new websites came out as new frameworks came out as new languages came out everyone basically followed existing standards odbc jdbc adio pdo etc right and so they weren't creating their own ways to access the database basically even when new languages came out sometimes they follow the sequel standard and implement some sequel like interface or adopt odbc or jdbc but today new implementations for yet another programming languages support to use yet another family of no sequel is invented as needed and that creates that picture there and and this is basically the thread that we see today we see very very few research on this topic apparently all of the open source scanners as well as the commercial scanners right now haven't put a lot of effort into studying threats that exist here however more and more and more websites are starting to use no sequel technologies so we've covered the general topics now let's look at the specific examples of vulnerabilities so we'll be we'll be looking at some examples of no sequel vulnerabilities including connection pollution jason injection view injection key brute forcing and key brute forcing sorry connection pollution using couch dbs example and couch db the entire couch db interface is implemented in restful uh which allows for cross database or cross pull axis through restful and all of couch dbs global and database handlers are also implemented in restful so the this creates some attack vectors that are easier than before um for example um if we can manipulate uh the connector here if we can somehow manipulate the connector here uh then without further manipulation just by manipulating the connector itself we can restart a couch db database and here's the list of all of uh well some of couch dbs uh handlers that would allow us to execute a lot of uh commands if we're able to manipulate the connector and uh for example uh the configuration itself is also um in a restful interface so by manipulating the connector we can also directly see the configuration of the database uh which which which actually took a lot more steps in sequel injection and here and a lot of people a lot of people a lot of people thought that okay so you can still manipulate data flow or you can still manipulate um sequel commands in a no sequel implementation however uh real sequels are very powerful uh my sequel database is a very powerful set of sequel commands which allowed you to execute uh system commands for example and then uh so even if you're no sequel even if my no sequel implementation implements a sequel like interface well most likely there won't you won't be able to execute uh database committee you can maybe you can uh you know manipulate manipulate my database a bit uh but you can't execute system commands well that that might not be true uh because in this example that you see here this is again couch db uh if i am able to manipulate the configuration uh through the restful interface then i can change uh the um the javascript interpreter of couch db and as you see here we've changed it to js2.exe which can be a file that we uh put onto the system or an arbitrary system command or um system executable so executing database uh executing arbitrary commands through manipulation of the uh the client interface is possible as well and then what makes it harder um even when an injection vector exists cross db cross databases is difficult uh cross databases was very easy with sequel injection because the sequel commands supported um naming of databases so you can jump databases once you can manipulate sequel command um but it is absolutely not true uh in most sequel uh in most no sequel implementations so traditionally what happens in a traditional sequel is you get connected uh you do sequel injection and then you jump from one db or one table to another uh this would this is difficult to do in a no sequel implementation um so what you need to do is uh you need to find ways um to inject variables uh to inject something into the connect screen uh for you to do that so so basically once the connect the connector is established you're limited to that context in most no sequel implementations so document based issues uh JSON injection as an example also using couch db and this is about uh data manipulation um so a lot of times uh it's recommended that you we do not implement our own JSON parser or handler but sometimes you just have to for example when you're handling very very large JSON uh replies and uh existing ones are just too slow uh but the key here is try don't repeat yourself leverage existing JSON implementation um because uh if you if we really want to implement one then there is risk because the troublemaker is a string type uh and if we don't um handle JSON well there will be JSON injection and when JSON injection happens in couch db that is directly manipulating the data stored in the database um so and the countermeasure is try to use collection types such as hash and map instead of manipulating the bare strings itself themselves and when handling tainted strings uh at least we must remember to escape jason and unscape jason now view injection i was using couch db view injection allows for application manipulation so couch db is scriptable using spider monkey as the scripting engine so these job scripts are called views in couch db uh redefine views and and so there's redefine views and temporary views uh and views are basically to do map reduce using javascript and which and they allow for and they're used to retrieve arbitrary data modify return values to manipulate control flow oh yeah so uh if we can inject javascript into um uh couch db ask views what we can do is we can then use that javascript data use that javascript execution to retrieve arbitrary data modify return values to manipulate control flow um and a lot of other things um so this is uh this this what we call um view injections basically when you inject javascript into couch db and so as you can see here is a typical example so right here as you can see the view the view is here and the map is actually javascript and it's executing it with spider monkey so if we can inject into this field then we can just we can basically do application manipulation so all these were injection issues in a no sequel application right so uh no sequel equals no sequel injections not necessarily not necessarily uh key value based problems uh in a key value based database we can at least do key brute forcing uh it's schema uh key value based databases are schema free so we don't have to get schema um so but then in a in a uh key value database we're doing key brute forcing the um the key now is how to speed up the attacks uh it really depends on the implementation of the client library and architecture the challenge is can we make sense uh context sensitive attacks meaning that we send a key and we do some static analysis and according to the the time in the calculation or the response differences we can say uh we can speed up this process and say okay this key we can make a quick judgment and say this key doesn't exist in the key value data store and that's how usually that's how uh it usually looks like and um and so we call this key brute forcing note that not we're not manipulating the data flow at all okay for example if uh for a uh for a video streaming website uh there there's uh for example youtube there's typically a key uh uh associated with every video um that gets fed into that gets eventually fed into the uh no sequel database to retrieve that piece of video so that you don't you don't need to manipulate anything for it to execute no sequel dot get key um but you can very easily brute force the key uh so prevention uh it really depends on how data is modeled because there's no schema so if for example you're we're storing all personal records in a single um key data store key data database uh database then uh once that is brute forced uh they can get everything out right so it really depends on how your application logic is segmenting the data how your application is modeling the data uh again there's no schema so uh data modeling is done by the application itself and the key size key space uh and also unpredictable key generation algorithm and also it can be challenge based for example uh asking for cap just and the impact on security technologies uh when these no sequel implementations are adopted by websites how no sequel uh technologies will would impact web application scanners um for traditional scanning how to handle unknown error messages meaning that for traditional black box scanners uh most of them rely on knowing uh existing error messages of sequel database and sequel databases and there aren't that many sequel databases and so there aren't that many formats to database error messages uh but here as as we saw there's going to be you know uh a big um wave of new formats to uh new error messages coming out and how would a web application scanner support all these uh error mess new error messages and then if we don't recognize the error messages how to do blind injections uh if a query languages exist how to perform logic based blind injections um and then can we do time based differential attacks based on static analysis as mentioned previously and then finally different types of attack payloads right now uh well-known scanners for example uh commercial ones web impact watch fire akunetik senzik uh they all have a good uh database of uh attack payloads to execute against uh uh a website in order to find for example injection flaws but how about for no sequel implementations um so first of all the different languages both in terms of data and programming uh for example for for data manipulation uh for which which by and by that we're referring to json injections uh what what what is the language to be used it's json so do we have a json uh based pattern database for our injection purpose uh and for programming language manipulation for example on couch db uh then we're doing basically view injections we're injecting javascript um do we have that type of uh payload database for us to test out uh view injections inside a no sequel web application um and then second one is uh the fact the the impact of a schema less implementation uh basically because the because it's schema less the attack surface is redefined why because data is modeled not by the not by sequel but by the application itself and therefore um the vector uh the attack vectors are very very sensitive to the entry points before it was not before it was it doesn't matter which url it really didn't matter what in which url we're finding a sequel injection when we find a sequel injection that's a sequel injection and we can jump tables we can jump databases we can execute system commands but here because everything as we saw previously is bound to the connector um the the the type of things that we can do once we can manipulate the flow the data or the application itself really depends on which url we're finding it in and so as the web developer uh or the application developer if they segment out uh and model out their no sequel implementation well uh their code would be a lot more secure um because um a lot of the entry points are uh not very useful even if they're attacked but then how would a web application scanner test for this and then there are different attack concepts that can be played for example key proof forcing uh proof forcing the key which is a very uh valid type of attack uh against especially uh just uh particularly no sequel implementations but are there any web application scanners implementing this type of checks and then um so selecting the payload requires understanding of the underlying database uh so how to blindly identify urls involving no sequel right so so when now when your web scanner or when your pen tester you go onto a website you see a url how do you know what's behind this url are there sequel databases or are there no sequel databases and if there are no sequel databases what what set of payload are you going to fire against that url are you going to fire uh jason manipulation or javascript injection um or are you going to fire fire traditional uh no uh sequel injection attack well there are ways to find this out uh usually uh no sequel implementations of the sequel interface will be a subset of the sequel 90 to 95 and uh however features uh that will impact parallelization typically will be removed for example union so when you when you when you when you when you start to see that you can uh manipulate this uh the sequel command but some of these uh commands are absent especially for example commands like union you know then it's probably a no underlying underneath it's probably a no sequel uh no sequel impacts on static analysis or source code analysis uh source code analysis checks by data flow so there's less of a problem but diversity is a big problem because you have to support so many you have to recognize so many implementations of um no sequel databases uh and so right now there are a lot of unsupported client libraries uh but in general it's a lot easier than web location scanners sorry uh no sequel versus web application firewalls uh keep root forcing is not an injection attack uh and uh it can be blocked by accessing thresholds uh by accessed thresholds for example and so uh web application firewalls has a good potential at blocking a lot of these attacks uh um a lot of these new attack vectors uh versus web application skinners uh and static analysis tools which are having hard time finding these because web application firewalls are uh transparent basically to the back end um or or or uh web application wafts can help also help do euro integrity checks uh for example it can add some kind of hash mac to the key h mac to the key definition of attack payloads is going to be a challenge so what is a data or json injection and what is a view or javascript injection right now uh wafts are very good at recognizing okay this is a sequel injection so i'm going to block it this is probably a cross-site scripting so i'm going to block it but uh how how will it uh develop patterns to uh to detect uh attacks uh against no sequel databases what are the patterns to these attacks that's going to be the challenge so conclusion uh threat analysis must be conducted under a no sequel mindset uh because a no sequel implementation is so different from a sequel the threat landscape is really really different uh modeling of data is done by the application logic and not the sequel statement or the or database schema and so the threat is very sensitive to the entry point so uh where you're finding the vulnerability becomes critical um and not just okay i found a sequel injection great i can do this and i can do that uh threat types are different for example new attack vectors are coming would come out and uh it impacts uh and so all of these would impact existing security technologies and we'd love to hear your comments uh because we're considering implementing static and black box skinners uh as as tools uh just for no sequel technologies but right now we're also ours because there's so many of them we're also ourselves are still in the research phase uh so if you like to join us if you like to uh um develop open source tools with us we'd be very very happy um so please uh send us come send us your comments and we thank you for attending the talk thank you um are there thank you