The Dark Side of Cloud-Based Database Engines

for that as we say in Israel Today George I will take the woman will take the clicker thank you George and now it's time for some double trouble double trouble everyone we've got a pair of speakers who share a first name and a passion for hacking databases now this is going to be a fast talk by a dynamic duo after which we'll enjoy another fantastic break but I'd like to introduce you to our two fantastic speakers I want you to give them a really nice welcome this is a field and Affair okay this is valenciano and this one is of Phil shatty yep I almost got to confuse myself it ain't easy so firenofir are really passionate about understanding how things work uh of your valenciano plays around on ctfs Capture the Flag competitions of Phil shot is a security researcher as well and he has published groundbreaking research in the field of database attack techniques they're both an offensive and a defensive perspective and that's what we like to hear right here on this B-side Tel Aviv stage so funeral Duo they're gonna take us into the dark side of cloud-based databases and database engines ready to to go all right take it away let's give a warm welcome to a field and a field perfect so hi everyone thank you for being here today uh actually we're very excited to be here and today we're going to talk about how the ships of the cloud has changed everything we knew about database attacks and exploitation so today when almost every single usage in the cloud involves at least one data asset and every data asset has its own capabilities like backup replication different authentication methods and so on and when all this feature kept to evolved so do the attack landscape around them and today attackers have more possibilities than ever in order to get access to your data in the cloud before we'll dive into the technical attack vectors that we found let's take a quick Overlook about ourselves so my name is Alfredo balaciano I'm the head of research at dig Security in my past I mainly focused on low level research and I analyzed hundreds of malware today my main goal is to protect your data in the cloud with me or Phil hi I'm office and I have experience with well application security and also with database Security in the on-prem and also in the cloud yeah by the way we have so many of you in the company so if there is any offer here you can send me CV later so what do we have for today at the first part we're going to talk about AWS redshift attack surface and how ofir and I were able to exfiltrate data and move laterally between different data services with almost single ratchet permission in the next part we're going to talk about our journey of discovering new vulnerability in gcp Cloud SQL and the way we broke the security layer on top gcp Cloud SQL and got access to the underlying host so let's start AWS threadshift as we may know is a database cloud-based data warehouse contains many features like backup replication IM authentication data share and so on and when ophir and I wanted to understand the attack surface around it we came across the following the following feature that we both thought it it's a good example to understand how a misuse of a great feature can lead to a risky waste so the default IM all gives you basically the ability to attach default role to your redshift cluster and from now on directive cluster will be able to interact with many other different data services on behalf of this all permission so the attack scenario goes like this imagine that an attacker got access to your AWS account it could be by a successful phishing attempt or any public credentials that they found now the attacker got low privileged stolen identity with two permissions redshift create cluster and I am a password now the attacker can create redshift cluster in your account but basically they got access to many more data Assets in your environment such as ec2 RDS dynamodb S3 and so more now fear will continue with the actual attack vectors inside this scenario thanks Sophia and hi everyone so in the following slides we are going to talk and see some of the permissions that we have in the default role and we will see how we can use them to our advantage or our attacker Advantage so below me you can see the permissions for S3 bucket and between their permissions we can see get object list bucket and many other permissions we can do it on every resource or S3 bucket that include redshift in its name but I want you to note that actually when we created the default role we chose the option of with no additional S3 bucket but still our policy include those permissions so let's see how we can use it but so we will start with the enumeration with the copy command but first let's try to do the same with our original AWS principle so trying to list the bucket the object inside the bucket we got permission denied and now we will use the copy command and if you don't know so the copy command allows us to load data from external sources into redshift cluster and we can do it from S3 Bucket from dynamodb EMR and dc2 and to do so first we need to create a table we chose to create a table with the name xfill for exploration which suggests what we are going to do with it so we will use the copy command slightly different instead of putting the full file name that we want to load from the bucket for example in this specific example we will put only the bucket name and it will cause the command to fail but behind the scenes if we will query the SDA load com commits table we will see all the file names inside this bucket and this is how we enumerate all the files in the bucket without any permission that we had before to do so now that as attacker we have all the file names we can start and exfiltrate them one by one and to do so we will use the same copy command but this time we will use the full file name and as you can see in the table below we loaded all the content of the employee CSV file into the table and we can see it now if we do the same with our original low privileged user we will get some access denied now let's continue and explore more of the default role so what we see here is the permission that our default wall got for glue and if you don't know glue is a service that allows us to easily integrate with other data services for example the S3 Kinesis or Kafka the permission that we got here are a create database create table and some other permissions again for only catalogs or tables glue tables that include redshift in their name and yeah another strong permission that our default role get is for the secret manager and you probably ask yourself why should we get a direct shift should get permissions to the secret manager so the answer is simple to connect to remote sources we can do it to connect to RDS databases to Athena or Hive and any other thing so the permission that we get is get secret value for secrets that include redshift and also we get the permission of list secrets for all the secrets in our AWS account interesting right so now if you remember we had a restriction with the copy command that allows us only to load data from buckets that include redshift in their name so in this example we are going to bypass this selection and here we will use the create external command specifically with glue with this command we can create external schema as the name suggests on top of different services so that we create external schema on the database called attack redshift and we will query the lake table you can see below the tape the glue table and but behind the scenes what happens is that the table the clue table is reference to S3 bucket and the name of the bucket is offer data Lake and it doesn't include redshift in the name so this is how we can bypass some restrictions and get access to more data in our cloud and here you can see some attack passes that we can do with our create external schema command and if you want to see the full attack methods that we found for redshift you can go and visit our blog about ratchet attack vectors Now by this we close our first chapter about redshift attack vectors and let's talk about some takeaways so as we saw in Cloud environments it is very hard to understand who has access to what and we need something more sophisticated than iterating one AWS principal permissions and in our case we were able to use a low privileged user with almost single permission to single service and we were able to access data in many other services and this is not unusual in the cloud which brings me to my to our next takeaway which is reduce your attack surface maybe it sounds obvious but it works and last but not least monitor we can monitor our environment in the cloud level for example with cloudtrail and we also can monitor in the service level in redshift we will use the audit log and now I move you back to a fear and to talk about our next chapter yeah yeah all right so now as promised let's walk through our journey of discovering new vulnerability in gcp first of all let's ask ourselves why Cloud SQL well fear and I knew that the cloud provider is any any other platform needs to do some modification and changes on top of the classic engines in order to integrate the classic DB engines into the platform moreover SQL engine specifically is not an open source so we know that gcp couldn't just modify the source code itself they had to build the security layer on top of the classic engine and that leads us to our to our research question that was if we can break the security layer the gcp built on top of the SQL Server engines well to answer this question we need to go back to some Basics so welcome to SQL Server 101 every time that you will create SQL Server engine four databases will be created by default the first the master database contains mainly system objects the second one is the msdb database we will talk about it later but it contains mainly the SQL Server agents and schedule jobs the third one is the model database that is basically a template and every change that you will perform in the model database will be affected in the databases that you will create from now on and the last one and it's our favorite the tempdb contains temporary objects for aggregation SQL results and so on from permission perspective we have the server permissions it gives you the ability to perform operations like create alter delete at the instance of the server level for example create new databases alter logins modify server triggers in the other hand we have database trigger database permissions that gives us the ability to perform operations a database a specific database scope for example create user inside the database create new table keep in mind that the cloud provider would like to give us the minimum permissions that we need in order to operate in their managed databases for example creating only creating new databases and operating inside those databases the minimum permission that we need in order to perform modifications on the default 4 databases so in this in mind let's understand how gcp created its security boundaries on top of this architecture to do so we can ask ourselves some key questions the first one is who are we and in SQL Server we are operating at the SQL Server again the next one is what is our permission and we're operating with the customer DB Roots wall the customer DB root role is a custom role the gcp created and does not exist in the in the classic engine and the last one is what does it mean from our perspective to operate with the customer debut form well it means that we are completely blocked we have no permissions to see to see objects no permissions to into the instance level um at this point we knew that we are operating at the customer DBU 12 and the first goal that we set ourselves is to uh to escalate our Privileges and to be able to run as the C submin to do so we can follow some uh some best practices for example only always know who we are what is our permission boundaries what we can and can do the second part is to enable audit it was really helpful by understanding the indirect impact of our actions in the degree the third one is to search for background processes that are running with elevated permissions that we can utilize and the last one and the most interesting is to trying to find some differences between the classic SQL engine a SQL Server agent engine and the modified one okay so well it sounds easy well we tried believe me we tried a lot and after some coffee shots we came across the following screen gcp we saw that we can't see only our SQL Server login we could saw internal logins too and not only we could saw them we could change the password and moreover we could enable them on the msdb database at this point we knew it was our first step toward our privileged escalation because at the first time we could operate with other permission that we started with so like a good researchers we started by playing with our new brand permissions and trying to uh create some custom jobs and while doing so we saw a job that gcp created called ad tempdb permissions job runs every time that SQL Server agent is restarted and basically what it does is runs a simple SQL query that gives us the SQL Server user a control permission on the temp database control is the highest permission that we can get at the database scope and it gives us an idea what if we can create a database trigger inside at MDB because we have control on the 10db and find another user that will pull the trigger for us and then we will be able to uh to run our code inside the trigger with the elevator permissions yeah so with database trigger in place we only need to find this background process that will execute with higher Privileges and take some action on the tempdb that eventually we grasp will grant us with a C submin so we went to our audit our dearest Trend and we walked through hundreds of thousands of Records until we came across this special record and what we can see here is actually a create user when we created a user from the gcp console this audit record was created and the user have been created in all four system databases including the tempdb and what's special about this record is that the principle that actually take this section is cloud DB SQL root and we were surprised when we saw it so if you didn't get a guess what happened just now so we will later let's take a recap so we created a trigger on the create user event which we'll call a function that will grant us with C submin privileges then we go to the gcp console and create the user which we know that behind the scene is done by a privileged user and and the user pull our trigger and grant us with sysadmin okay so not this admin but DB root all which is pretty good and let's do a quick status check we wanted to get to CS admin but we got only the root role so we have path to go but let's see what we have so on the left side we can see the Privileges the original privileges that our SQL Server user has and we can see around 12 privileges around them and some view permission on the server some connect and insignificant Alters and our after our previous escalation we can see that we have couple of more permissions but more importantly we have the control permission which allows us to which is the most strong permission that we can get on the SQL Server but it's not enough because since we are not part of the seaside mineral we do not we are still impacted by deny statements so this is not a real full control but look at this interesting permission we also have impersonate any logging which is our door to our second privilege escalation we impersonated essay and granted ourselves with sysadmin and now acting as this admin we started to find our path towards command execution so there are many known techniques to execute code on SQL Server we started with CMD exec in the SQL agent we tried Powershell we tried CLR assemblies and xpcmd shell but unfortunately none of them work because for our surprise we were running over Linux more specifically a Docker version of SQL Server so we had to try harder and as this admin we have a full control we could read all the files in the file system we started to extract secrets and passwords but at this point we got a surprising email from the gcp team that asked us to stop our research so we work together with Google to disclose the vulnerability and actually we found it on February and by April the two own abilities was fixed and by that we close our last chapter about the cloud SQL vulnerability so it's time to sum up and first of all Google are awesome no but for real they gave a very quick response and fixed the vulnerabilities very very quickly and we saw that in the cloud we have the cloud brings new attack vectors to the table and we saw in this presentation two examples for a different kind of attack vectors that can be utilized in the cloud and while not everything is in our control like cloud provider vulnerabilities we saw some attack buffers that are in our scope and the main point that I want you to take with you from this presentation is that our data in the cloud has many passes to it and and it is a yeah so it has many patterns to it and not all of them are obvious and attacker knows it and use it and last uh I want to talk about the security in layers so Security in layers are in depth we saw a such good example for security in layers with gcp where they implemented the docker inside the VM but it also highlights the importance of permission management the fluidity of permissions in the cloud so it emphasized the importance of good Cloud architecture and permission management thank you all for listening to our talk and I hope you enjoyed and if you want to learn more about the topics that we just discussed feel free to go to our site at big security yeah oh thanks all right all right all right all right