 Hi, everyone. So today, we're going to discuss about EW's law-abiding activities and the security factors that can be applied. So before we get started, there's a little bit about me. I'm a security analyst at AppCircle. I just love to break my reputation if you are in cloud security. I'm a member of different communities such as my InfoCycle, Spreading Circle. I'm an active speaker who loves to share her knowledge with the community or any conference. A agenda of the today's talk is, what are the possible added vectors for the EW's cloud? Recognizing that help to identify those added vectors. Some of mis-configuration, like ion mis-configuration, S3 mis-configuration, EC2 mis-configuration, we're going to discuss today, and detection that can help to identify those mis-configuration and the security controls. So what are the possible added vectors? First is live credentials. Second, instance mis-configuration, like you found the EWC's network is publicly accessible. AMI is publicly accessible of the instance, right? Then EC2 instance having the CV against it, or the particular EC2 instance is publicly available, right? Those are the instance mis-configuration. In using default settings, for example, or you didn't enable that for the S3 bucket, right? That you're having the sensitive information, and enable S3 with KMS encryption. Then it's again, you should pause what if someone get your S3 bucket data, and that is even in the plain text, right? For example, not encrypted. For example, it's having the predictor details or the credentials, right? So, like you should use, but one of the reason it's default setting and another is like you haven't used the MDAVS2 version and that leads to the, this is how I found it, right? S3 mis-configuration, like allowing public access or allowing any user of the EWS to perform any action on S3, right? So S3 mis-configuration. Then access control makes configuration like you didn't mention, hey, this particular user should have only this much access and you are ending up giving more privilege that that particular user is supposed to do and that can lead to the external attack vector and as well as internal threat, right? Exclusion of the resources via firewall, right? So if you didn't configure the firewall properly, you're ending up giving your resource access to any user over the internet, that's most dangerous. Then network security mis-configuration, if they are VPC, it's not properly configured or you're imbued out, it's not properly configured, right? Then it's again issue anyone on the internet can access, right? Insecure customer application. So if the web application hosted on EC2 is not properly configured or it's vulnerable to like SSLF or LFI, then it's again issue because a ticket can get access to your AWS credentials. So you know that, hey, these are the possible attack vectors. Now, how can I find those? For that, you have to perform mechanisms and I have covered different ways to perform recognitions for finding credentials or finding the EC2 instance or to finding S3 bucket, finding credentials. Look for the hard-coded credentials storing Chavascript and AWS cognitive credentials in the response, you can find it. If like, how do you find it? I have access to screenshot, I'm going to discuss how can you find it, right? Then if the web application hosted on EC2 instance is vulnerable to SSLF or LFI, then also article can find those credentials. Code repositories such as feed bucket and GitHub, on that also you can find that in public. For example, out as many companies publicly expose their code on GitHub, that's all right. But if you are storing the credential on the repository, then it's issue, you can just order any etiquette and find the credential on GitHub and you are ended up like getting exposed your credential on the publicly repository such as GitHub and BitBucket. Then AWS error messages such as access denied and in the list sometimes if the properly not considered right, it just discloses that this isn't access denied but your credentials are this, right? So that's issue. Publicly be a snapshot. That EMI, that EMI related credentials being left in the public images. Then S3 bucket is also sometimes organization store that employee credentials or the admin credentials being stored in the S3 bucket, right? Then it's again issue. Please don't discuss an upcoming slide that how can you find those. Then RDS public snapshot. In those, you can find the RDS related credential, database credential information. Then people looking for help online, ending up copy paste in that complete information. Like they say, hey, I want that I'm facing this issue. This is some micro credential already is already in a piece help me out and that ending up getting at a time that, hey, this work credential belongs to this particular reason. So these are the standard record techniques that can help you to get started with the finding credentials, right? So one of the, I have mentioned that in the response, the cognitive credential being left. So this is how it looked like. Now for the C2 misconfiguration, right? So how can you find the public EC2 instance, right? For that, you need to have the access, right? So compute one EW, AmazonEWs.com, you mentioned in the census and you will have the list of EC2 instance and see if those are the EC2 instances publicly accessible, right? Then you can use Google Doc, you can use showdown as well, see in search you can apply and you can customize the result based on what you want, right? So query based on that. Then another instance already accessible to this IP address, right? Then and there is no prevention against it for the SSH, right? Then you can just do SSH on that particular instance. Same way you can access the MySQL database as well. Now you must be thinking, hey, how can I found the RDS? And basically you can mention, so it is this and RDS, AmazonEWs.com, so use the Google Doc. For finding S3 bucket, you can use Google search, Google Doc, showdown, census, use OSN tools such as servlister and AMAS, the force of naming, like the standard piece of what S3 bucket, right? Naming conviction is that S3, like site S3amazon.com, right? Or S3 Amazon, S3 site Amazon EWS, right? So these are the standards, you can just propose it. Or in the DNS record, right? You can also find the S3 bucket related information. Then certification and transparency law, then you can use numerous bucket or finder scripts such as there are so many scripts available on the internet such as lazy S3 bucket file, right? So you can use those as well. And credit or credit bucket search, you can use to find in the S3 bucket. I have mentioned that how can you find the S3 bucket using Google Doc, so this is the way you can find it. After knowing that what are the other factors and how can you perform the reconnaissance, you should look for the misconfiguration related issue, right? So one of the... I have covered as misconfigured S3 bucket. Now why it's misconfigured? Because of the policy, okay? So what is this? You are allowing public access to any... So for explicitly using that object can be public. So anyone on internet can access this bucket. Most strangest one is defining full access to authenticate AWS users group. So I think anyone with having the valid AWS credential or the authenticated users can access my bucket and even perform copy, read, and the delete operation. So you are basically affecting full CIA triangle, right? So it's most strangest one, policy to be in. Then bucket policy with the read access policy. So some organizers can say, hey, we have allowed the read access policy, but you are having in the bucket the sensitive information such as PIA or the purchasing stream formation or credential itself, right? So you should avoid bucket with the read access policy. Then you almost forget about interrupting your AWS S2 bucket. So for example, the bucket having the sensitive information and someone got access, right? And download the data, like purchase history or the credential and your bucket is not encrypted. Then they can have the full bunch of the credential that has been stored or PIA information or credit card it is, which is stored in the bucket. But what if you have applied the encryption technique then even though they got the bucket, but they are not able to get the data that, hey, what are the data available? Because the attacker is not having the master key. So usually it was like, so what are the vectors we have covered for the bias and mis-temperation happen, right? So far. So allowing public access to bucket, defining full access control to authenticated AWS user groups, defining bucket with the read access policy and enabling write access to everyone group for getting to interrupt your AWS resources. Now you've got to know, hey, this happened. Now how do you investigate? Or what can be done to investigate or what configuration or what services can be used, right? So guard duty help to finding S3 well list and S3 bucket and bucket ERN. And you want the bucket owner in the finding details. So you might have the fair understanding, okay, what's the ERN of that particular bucket and who is the owner of this bucket, right? Then you can use AWS cloud trail of like at what time the request being made from which IP the request being made, right? Or you can use trusted advisor. If you configure your S3 bucket, right? And you have allowed the public access that if the trusted advisor is enabled then it will give you alert, hey, this is not how you configure, right? Then cloud watch metric is again the best you can use to get the alert, right? For example, that is get request happen, or the delete request happen for your S3 bucket. Cloud, if you configure the cloud watch metric then you will get the alert that, hey, this is a request being made from this particular resources, right? So it's good to have enable config the AWS managed rule. There are two rules you can choose S3 bucket read prohibited and S3 bucket public right provided based on what applicable to your organization, right? So based on that you should configure all this. Now you configure all this but how do you investigate that, hey, this S3 misconfiguration happen, how can I invest in? So you should have proper logging mechanism in the place. Now after investigate or all the alerting in the place what security controls can help to prevent from the S3 misconfiguration. Implement list privilege access, right? Don't allow any authenticated user or any public user to have access to your S3 bucket. Use IM rules for application and the AWS service that require Amazon S3 access. That enable multi-factor authentication at least for the delete operation. So even though a attacker got the credential and able to delete your bucket but he might not able to delete your bucket, right? He can just only get the data. So every department will be not being compromised considering corruption at data rest because even though attacker will get the bucket, right? But the data itself, it's encrypted, right? So, and the attacker is not having the master key. So this is how you can prevent your confidentiality as well. Enforcing SSL, no standard preface. Consider VPC endpoint for Amazon S3 access but if you are having large organization or any organization and you are saying that, hey, this S3 bucket only accessible, this organization employee, so you should consider mentioning VPC endpoint, right? So as I mentioned, the S3 bucket having sensitive information, it can be having cloud-free log as well, right? So, yeah, one of the things consider S3 object log. So it prevent being the object data being deleted, which is present in S3, right? So S3 object log. Pre-sign URL, you can assign to the authenticated user. So only the user having pre-sign URL can only access this S3 bucket. Most preferable than NML versioning, a tiny change happen when you version work here. So this is how can you track the S3 related operation. Second is you found the credential, okay? You might have been, okay, I found the credentials. Am I just supposed to file it or say, hey, I found the credentials, that's it? No, you should integrate the permission. So this is the standard flow I follow. Got the credential, I try to integrate the permission and see what kind of access I'm having, right? Although what kind of access I'm having using victim credentials. If I'm having any S3 bucket related or they see to instance and try to get sensitive information, after that, is there having anything that I can perform the privilege escalation? Yes, so this is, you should also take care of it. If not sensitive information, is that policies not assigned properly to that particular user? And if I can perform the privilege escalation and get the sensitive information, so this is what your attempt flow looked like when you got the credential. So yeah, as an attacker, I got the victim credentials. Now I'm trying to integrate the permission and found that the user having the IM related and the user can list anything. But what interesting to me that is having STS permission, okay? But still it's not having like I can have the access to S3 or just download the data or do what I want to do. So what can we do? So we are aware that we can use the STS. So try to get who is the user and is there any policy attached to that user, right? So yeah, this is the way I found the user and the policy being attached to that particular user. Then try to get the policy and see what kind of policy it has and what is the default policy. So default policy is version one. Then list out all the policy available for that particular user. So that might have an older or the misconfigured policy or the only permissive policy that might help us. So you should look for all the possible policy. So we found that there are five policy available. Then enumerate different policies so that you can have the idea of what kind of access you have. So previously we had to go get and list permission but we found that, hey, if I having the admin level access, why admin level because Action Star, so Star that explicitly saying that you can perform anything on any resources. So admin level access. Now at the same time, hey, what can we do? Make this policy as a default policy, right? So I just made this policy as a default policy and no error message came. So we showed idea, we are able to make this policy as a default policy and the privilege escalation happened. How from get to the pool read, write and update operation we have, right? You can do anything on any resources. This is the POC for that, like how, what kind of privilege I got after making that policy as a default policy. So, yeah. So what was the upper sofa? You found the hardware credential, like one of the factor was you found the hardware credential, you try to integrate the permission then you cut the IM related access, you try to integrate the policy and one of the policy was having only permissible permission like admin level access and we tried to make it as a default policy and it was successful. So when you find the credential and that was not having too much access, don't give up, see what else you can do. So this is how we can go beyond. One of the test is so, yeah. So I have included the POC that how can you do the same actions from the management console. Basically, I'm doing the same thing from the management console. See, this is the report here having the admin level access and I'll try to make it as a default policy and see the permission now I'm having is a admin level, right? So now all things you found that, hey, my credential didn't compromise. This policy was only permissible, right? So to avoid this, right? So what can be investigation or the detection services for the investigation or detection purpose because you can use the services or the tools to identify or to get alert, right? So for that, you can use trusted advisor or the check I am credential report to check or like when the last credential being used at what date, at what time to use, right? Then use I am tools such as I am policy simulator so that you can just see, like you can simulate the policy what kind of access this user have, right? Use config rule to see what are the policy in the use that so you can use this rule, I am policy news that conflict rule that checks whether I am policy ARN is attached to I am user, right? I basically specific this policy rule because this is relate to our attack scenario, right? You can apply many rules. I just mentioned one of that. Then you can use access advisor get the information about last access information, right? And what kind of access happens? Use crowd trail for the logging, like if the request obviously being made, right? Then at what time from which IP it has been requested, right? So you will have the logging information for investigate and analysis and to take step forward. You can use monitor cloud watch alarms to prevent or to get alerted in the future, right? So for example, you can enable for group logins if any I am policy changes happen that is also you can record, right? So you can get alarm that this policy change so you can directly perform action. In this case, policy change and I made it admit. So you should just have the cloud watch alarm active that you didn't notify for saying. Then seeing unauthorized API calls happen then again, you can being alerted. Cloud trail configuration changes happen. Authentication fell off. All this you should be taking care of it. Now you have been alerted and detected how my credential being leaked or compromised. You will be like, what should be done, right? So for that, you can just basically create the new credentials and disable the previous compromise credential and remove it. But making sure that you are first creating the new credential and then make a, deactivate the older credentials so that if you directly remove the credentials then you might be your website maybe break down or not like web application will not work properly, right? So making sure that you follow this standard approach. So far what we have done that we create the new credentials, disable the older credentials so that no longer use to your access account, apply list privilege to that particular user and our creating user with access to your permission. Now security controls that can be applied to prevent from this kind of issue. Use to create manager to store your credentials securely, grant list privilege access, use access levels to review IM permission, right? Configure a multi-factor authentication for your most sensitive information like delay or removing the cloud or cloud configuration changes, right? Anyone multi-factor authentication, rotate your credential regularly and enter log metrics, return alarm access for IM policies. So you just get alert and you take the action, right? So these are the controls you can apply. Now another scenario I have covered that what it feels on the public IP of the EC2 instance. Now how, why I'm finding this, right? So a possible is misconfigured firewall happened, right? No properly in bound or bound rule has been mentioned. So that's why EC2 instance publicly accessible to you. Now you've got the public IP of the EC2 instance what should be your next step look like, right? Is there any default configuration being used? Is there any ports are open? Is web application running on this particular IP? This is, you should must look for, right? I will give you overview why because I have covered the bottom of the scenario. So, okay, so I found that I got the IP and this particular IP having the web application running on port number 80, but it's saying that URL must be string non-define. Okay, so I got that something URL parameter being used. So here I say URLIFCONFECT.COM and I got the IP address of the, so okay. So I said, okay, this is vulnerable to SSRI. Okay, so, but you should not limit self-reheal. I found the SSRI, if your application is vulnerable to SSRI, you should start digging into this particular ability that the web application vulnerable to SSRI is it's posted on EC2 instance. Okay, rule is attached to it and try to get the IBM role credential and see what kind of level it says you might ending up finding admin level or S3 bucket data. So this is how you escalate security severity, right? So here we did same and we found that, hey, this is what the role attached to it and this are the security credential. After getting credential, you break permission and we found that, hey, S3 related permission and that also having the credit card details and the admin credential in it, right? So you just using command to copy or the get data in your system and I was able to get the admin data, right? So now we can think of like what kind of SSI I am having as admin. So just moving to IP to the admin level access, right? So just let's do a tech surface analyst why this happened. One of the factor if all configurations are in usage, right, you are just allowing to EC2 instance publicly available, misconfigure firewall. Web application posted on EC2 was vulnerable to SSRI, right? Like no input validation was there on the web application. The role was having access to work with the S3 bucket and the data storage in EWS S3 was not encrypted. So for example, even though article able to get the S3 bucket, but if it's encrypted, how do he get the like credit card details or admin credential, right? So that you can, you could have like the prevented sensitive information being stored on S3 bucket. You should not actually store the admin credential or any of those credential in S3 bucket. So you may feel like, hey, this is most similar sound to like capital, yes. So in the capital one bridge, the similar scenario was that this configure firewall was able to gaining access to EC2 instance and that is vulnerable to the SSRF and gaining the IM role that is allowed to access S3 bucket and in the S3 bucket, he found the credit card details of the users, like millions of users. So for this particular scenario, what were the attack vectors? Web application hosted on EC2 instance is vulnerable to SSRF, IMDVS version one being used in proper bucket policy, students sensitive information in the bucket for getting to encrypt S3 bucket data, right? So I can summarize that misconfigure firewall, right? One of the attack vector, S3 misconfiguration, right? Why S3 misconfiguration? Those are the explanation for that. Default setting users, see? And the vulnerable web application, this is vulnerable to us. So this is how you can pour like the attack vectors. Now you get to know why this happened, like, in future, how can you do that, right? So you can use guard duty. If there is any C2 misconfiguration or compromise happened guard duty will help you to identify conflict rules that specific for EC2 IMDVS version two check. It basically check that if EC2 instance metadata version is configured with the instance metadata service version two, right? So that is most important thing to prevent from the getting IMDVS potential. Then security hub, it will just give you whole analysis, help you to identify that related to conflict rule, IMX analysis, that guard duty, all the findings you can get in the security hub. So you should use security hub flow logs, like to see like VPC flow logs from where the traffic is coming from, right? System manager for the properly configured EC2 instance, right? And you are aware that your EC2 instance is compromised, but one step you should take, right? For that invalidate your temporary security to create a check immediately, stop compromising EC2 instance, take the snapshot of the EBS volume so that, and deploy that particular instance in isolated environment, that is being compromised. Isolated basically new internet access and ideally private subnet, and then read through the logs to figure out why, right? To prevent this kind of attacks in future or misconfiguration in future, you can use the input validation to prevent from SSRF, update your EWS EC2 instance metadata services. So even though it's one of the two SSRF, you are still, the user will not get the Ion Road tradition, right? Then implement list privilege permission so that the editor will have the list privilege access. Consider encryption of data address. I'll mention that by I mentioned. Then constantly monitor only permissive security use, use a control driver for the separate logging activity and normal account activity. Security groups by its matter, because you can just mention that only the user which are present in the security group that only allowed to access this EC2 instance. So you can avoid the publicly available EC2 instance and why do separate logging? So even the article board access to your credential, but he or she cannot remove the cloud trail of any logging mechanism. And then use security hub, right? Like to have the whole analysis on it. So things to note that you get to know about the attack vectors, right? You become users and those are the key to finding those attack vectors. Most exploitation has no limit with the cloud. So you should like keep looking for the attack, additional services like disturb logging and make code changes to attack users, right? Like, like, internet security teams can shake what can be done so that in future, what if your credential being compromised and another outsider attack to anything with your services, right? So making sure that you always apply that least privilege access to any user role group. So that you at least avoid the attack surface area. And the most common things we have found is configuration of services, insecure programming practice and insecure permission, like over permissive policy has been there and that leads to the whole account takeover. And the must take the follow EWS security best practices to avoid or to being driven from being compromised or any women from being getting rich in future, right? I just mentioned some guidelines and tools that can help. So these are the guidelines, EWS white papers having the good documentation around it, EWS security audit guidelines, then scout suit for the automated CIS auditing, right? Benchmark auditing for the multi cloud. Roller is basically automated auditing specifically for EWS, S3 inspector to analysis what kind of permission having, right? Like you got the credential and we want to see, okay, what kind of, you don't want to move manually, you can just use this tool and see what kind of permission you have, like it's publicly accessible or it's having the authenticated, any authenticated user can perform any action, right? So it will give you information around it. Numerate IM, you can just enumerate the, what kind of user, like what kind of access the particular user having and back over the penetration based in purpose. It's a penetration based in purpose. If any question I ask, question and answer, I move one further question and answer and you can connect me on LinkedIn and Twitter.