Cloud Security Testing in AWS

View Show Notes and Transcript

Episode Description

What We Discuss with Pawel Rzepa:

  • What is Cloud Security Testing and Assessment ?
  • What is a Cyber Kill Chain in a cloud context?
  • How to get started in Cloud Pentesting?
  • The need for Cloud Certification and recommendations for Beginners?
  • Is there something people are not talking enough about in a Cloud Security context?
  • And much more…

THANKS, Pawel Rzepa!

If you enjoyed this session with Pawel Rzepa, let him know by clicking on the link below and sending her a quick shout out at Twitter:

Click here to thank Pawel Rzepa at Twitter!

Click here to let Ashish know about your number one takeaway from this episode!

And if you want us to answer your questions on one of our upcoming weekly Feedback Friday episodes, drop us a line at

Resources from This Episode:

Ashish Rajan: Hello, and welcome to another episode of Virtual Coffee with Ashish. I am Ashish and today we are talking about testing for security in AWS. If you are a pen tester or someone who’s starting how to do security research in a cloud, specifically, AWS, or maybe even other cloud service providers.

This could be a good podcast episode for you. I’m going to bring my guests in.

Welcome Pawel Rzepa,

Pawel Rzepa: really, really good. And thank you for having me

Ashish Rajan: here. No dude, thank you for coming in. And by the way, for people who don’t know Pawel is awake late in the night for me. I do appreciate I’m sure the audience appreciates it as well.

So I’m going to try and get to the meat of it really quickly as well. But for people who may not know you, how did he get into cyber security?

Pawel Rzepa: So I was interested in cyber security for a long, long time. Like since my university and I started my professional career in IT support, but I knew [00:01:00] that I wanted to work in cyber security.

However, I. Wasn’t sure about which branch of cybersecurity. I tried to work as an internal auditor in a bank. I tried also to work as a threat analyst in IBM security operation center. I even develop some definitions for next generation father, but finally I found my place as a penetration tester and And yeah.

So now I’m doing a variation of the pen testing that testing cloud,

Ashish Rajan: I was gonna say that’s a really interesting experience for you to come into the pen testing space as well, but

what does cloud security mean for you?

Pawel Rzepa: To answer this question I would prefer to start from answering the question of what is the purpose of security at all. And I liked the definition that the purpose of security is the ensuring that your solution works as intended and only [00:02:00] as intended.

So going back to your initial question What is the purpose of cloud security for me is that practice of ensuring that your cloud resources work as intended and only as intended. In other words, ensuring that there’s no backdoors exposed data, additional resources like cryptocurrency, miners, et cetera.

Ashish Rajan: Actually, that’s an interesting one because, and this probably is one of the most important reasons why people do cloud security assessments as well. And it’s I find it really interesting when people say cloud security assessment, they always assume it’s pentesting, but then there’s the research side and all these other factors as well.

Can you clarify for people what, when we say cloud security testing or cloud assessment, what does it really is?

Pawel Rzepa: Yeah. So in short, I would define cloud security assessment as a practice of ensuring that your cloud resources are [00:03:00] safe. For me every cloud security assessment should start from understanding how the cloud is being used by this particular customer, because.

Every customer is using it a little bit different. So specifying what our key assets and what data you need to secure. So in my in my opinion, we should highlight four main pillars of the cloud security assessment. That is the first one is the architectural review. So. Ensuring that there aren’t any design flaws or unnecessary resources like mentioned extra instance with running cryptocurrency, miner, mining software.

The second pillar is penetration testing of exposed services. So for example, ensuring that there are no vulnerabilities in your cloud applications or there’s no vulnerabilities in your several the scope. The [00:04:00] first pillar of cloud security assessment is reviewing the monitoring. That is verified that there is the incident response procedure and that you have the ability to detect and react to indicators often misconfigurations as well as indicators of attacks.

And finally, the last pillar of cloud security assessments should be the configuration review. So. Detecting any services? Misconfigurations like detecting publicly available SQS queues or S3 buckets, but many people. Is there a cloud security assessment as only detecting misconfigurations, but that’s, unfortunately it’s not enough because you will not know who should have access to work.

You will miss any design flaws. You will not be able to react if an internal user make your data public. And if someone compromises your Lambda functions, for example, there may [00:05:00] be. No need for any misconfigurations because the article already has access to your cloud. So cloud security assessment is not as easy as just playing the battle and running the automated, scanner.

Ashish Rajan: I love your definition of the cloud security assessment, because any people who might be using a cloud security posture manager, well, I guess all the salespeople who do cloud security posture manager may have to rethink that because it’s only part of the problem that you’re solving by saying you’re scanning a configuration.

And it doesn’t talk about the design flow in the architecture and it doesn’t really talk about the fact that, Hey, this may be a genuinely required character of this S3 bucket that you have to have it open. But the configuration to look like this is bad. CIS benchmark is breaching, blah, blah, blah.

So I do appreciate I do love the definition. Another one that confuses our people, the cyber kill chain. And what does that really mean in a cloud context?

Pawel Rzepa: Yeah. So [00:06:00] the kill trick there originally came from the military concept related to the structure of attack and the cyber kill chain is a cyber attack life cycle that helps to identify and prevent cyber intrusions.

In other words, a cyber kill chain is a structure of a cyber attack like recognizance then delivery of our park back during the access to make. Persistent access and so on. So there’s the MITRE attack framework which is app great knowledge base of a diversionary tactics and techniques observed in real life attacks used, for example, to detect the attack, the activities of real world.

Apt groups. Now APT is an abbreviation of the advanced persistent threats. Such APT group tends to use similar tactics and tools to do a reconnaissance and then deliver the next phases [00:07:00] of the attack. Now, what do you can do with it? This knowledge gives us information, how such attacks looks like. So how should we protect them?

How, how should we protect ourselves from them as well as how to discover them on the very beginning of the attack and simply stop. So I recommend everyone to Google their clouds, Metrix on the MITRE attack website. And take a look, what are such attacks tactics and you will learn the next steps.

An attacker may do like how it is possible to escalate privileges. What are the ways of persisting in access in the cloud? So whether or not the attacker may put the backdoor and. Finally how in attacker may erase their fingerprints of the attack, like removing goal logs and so on. So this knowledge may give you ideas, how to prevent such tactics.

Like for example, if you are using the [00:08:00] AWS organizations, then you can use service control policies to deny such dangerous actions like removing your logs. So. Even if an attacker will escalate a privilege is to an administrator in this AWS account. The article will not be allowed to to remove any logs.

But please be aware that in MITRE attack framework, this is not a full list of such tactics. But it’s definitely a good point to start.

Ashish Rajan: That’s really awesome. And I definitely recommend people check out the attack meter as well. I’ll add the link in the show notes because I feel sometimes the hardest challenge is to know a starting point and exactly what you said.

It’s a great starting point to go into a attack matrix and see how do people do reconnaissance and how do people kind of find a way into cloud as well? So, great answer, man. The more we talk about this more, it sounds like threat hunting. So is threat hunting in cloud security assessments. [00:09:00] Same,

Pawel Rzepa: Not really.

They are for sure. Different in their area of focus. So you can, watch talk regarding the differences in detecting that indicators of misconfigurations and indicators of attack. So cloud security assessment is focused on detecting such indicators of misconfiguration.

While threat hunting is focused on indicators of attack. And of course you’re using different tools and approaches to detect that. So to give you an example, detecting publicly open S3 bucket is an example of such indicator of its configuration. While if you detect that somebody is firstly running the STS, get color identity to find out name of compromised throughout, and idea of AWS account.

Then lists all your backup names and then starts downloading old files. Well, that may indicate for an attack [00:10:00] and probably such keys should be quickly disabled to stop further attack and start investigating what is going on.

Ashish Rajan: That’s a subtle difference, but okay. This is the area of focus as well, too. If it’s like different area of focus. Would this be something that I need to ask permission for you to, how with the pen test you need to request permission, or I guess at least you used to request permission from AWS before you could request or do a research if at the same thing with this as well that you need to ask permission from AWS before you can do any of this.

Pawel Rzepa: Nowadays in short, such permission is not required regarding penetration testing of some common services. EC2 Service elastic, Beanstalk Alumba or or LightSail? I find like it. Nowadays because some years ago it was required. So at the beginning of my cloud security assessment, I have to ask for permission.

But that only shows how things are dynamically changing in cloud. So you, [00:11:00] should know, however that there are some activities which are prohibited like testing denial of service attacks or portfolio. If you want to do a full port scanning, Of multiple Amazon IP addresses that traffic will be quickly detected and rejected.

So from the testing perspective, that will look like that this host is down, or all the ports are closed. So if you’re going to test a host in the cloud, Then you should start from reviewing the security groups and take a look which ports are publicly open. For example, if your EC2 instance that you are going to test a have open port, let’s say 80, 80, but on your security group, there’s only a port for four pre open.

Then you won’t be able to interact with IPA.

Ashish Rajan: Yeah. To your point, it does make sense from a perspective of if [00:12:00] AWS is allowing, I guess, EC2 and other services should be tested freely, that means obviously they have a lot more confidence and lot more monitoring in that space as well.

So if people don’t want to get banned by AWS or their AWS account being banned by AWS. They probably should consider getting a permission if it’s required for the service. I think we’ve been talking a lot about it from a beginner perspective cause we have, I guess, both kinds of audiences we’ve got audience, which is I guess, experienced pentesters as well.

So from their perspective, they’ve traditionally gone onto, on-prem looked at web apps and I guess ran what they would normally consider recon and all other kinds of strategies to kind of get some account takeover. Right. Is this something that transitions the same way into a cloud as well? Or is this different

Pawel Rzepa: in general?

They’re similar, they may be similar. But there are some differences. So as I mentioned, there are prohibited denial of service attacks. So when you’re testing on-prem web server, [00:13:00] then probably that would be a good idea to test it against let’s say slow HTTP, but in cloud, that is not going to work.

And if you do it, your IP can be even temporarily blocked. What actually happened to me once all the traffic is going from one address from our VPN and doing some extensive tasks. And then when we tried to anonymously access the S3 bucket, which is publicly open, then I got there 403 error that sorry, access denied.

And other defenses are the consequences are of some vulnerabilities. And I will give you a good example. I think so. So for example, if you have the server site request forgery, a vulnerability in the on-prem application that is isolated from the rest of your network. You [00:14:00] probably want to do much with is more vulnerability, but the same SSRS vulnerability in the cloud application may result in accessing that instance, metadata service what means an article may get AWS access keys of the role attached to this particular EC2 instance, getting an access to some of your internal AWS service.

And I read one of such reports from hacker one website, which is by the way, a great source of knowledge about nice hacks and real world hats and vulnerabilities. So there was a report and an SSL wrap vulnerability, but it was marked as information out because there wasn’t any, any serious risk. Abs of course the researcher didn’t get any bounty for his finding and.

Then this the same application was migrated to AWS with of course the same, not fixed vulnerability. [00:15:00] So another researcher just reopened this, these tickets the, because now it was possible to access the metadata and get those keys and exfiltrate some data. So now the same vulnerability was marked as critical work.

The other example of differences can be something what I found several times during pen testing and application, which was actually the hybrid that was hosted on prem about use some AWS services. And. It occurred that there were hard-coded AWS access keys in the JavaScript or somewhere in the in the traffic and under the hood, I discovered that all users are using the same AWS access keys.

Now from the application perspective, Your user was able only to see his or her files. But when you [00:16:00] saw the traffic that is going to the server, you could exfiltrate those keys and then use those keys to access the bucket and get permission to access all the files, including of course, other user files.

Ashish Rajan: You’ve already mentioned quite a few things, which by the way,CIS benchmark or any of the other cloud security posture management tools that are out there that give you the thing that you can secure your cloud. Like, for example, that it doesn’t look for shared access keys between users, like things like that. I find it really fascinating that you’ve already mentioned a few things which are usually considered the best practice, but you know, something that worked really well and was a low. Bug in a on-prem context suddenly became a critical one in a cloud context, which I love the example of man. I think it’s really interesting so if I’m a pen tester and I’m looking at my application, which is in a cloud environment and I’m trying to [00:17:00] pentest it.

So I guess it would be cloud native angles and cloud. Well, some people may not know what cloud native services are. Are there any cloud native services you can define if you want cloud, right. What is cloud native, but are there any services that you recommend people start with in terms of where should they start researching?

Pawel Rzepa: Yeah. Well That would be for sure that the most known probably as free service. So yeah, there are still a lot of issues related with this service. However also quite common, but much newer is for example, that Lambda service and. Once I made a research that I uploaded to the official NPM repository.

So basically the package was responsible for renaming the objects in S3 bucket, however Silently the same package was verifying if there are if among the environment variables there is. [00:18:00] AWS access key ID. And if so, then this key was exfiltrated to my server because by default, a Lambda function role, a role that is attached to the lambda function keeps the AWS access keys in the environment variables.

And by default, all the traffic is egress traffic. So outgoing traffic is is enabled. So. I just, you know, put it without without announcing it to the world. But after four or six weeks, there were around 500 downloads of this package. And my server trust me or not, but 20, 20 such keys I collected only the AWS access key ID.

So with that, AWS access key you cannot do much harm. So I was just doing it for the, you know, educational purpose

[00:19:00] right?

Ashish Rajan: This is all for education purposes. People we are warning you. You do not try this at home.

Yeah, Pawel Rzepa: I can I can guarantee you that. So it works. However, this is approach shows that there are still blindly around the code found in the internet without verifying it.

I know that it is not possible to verify all your codes. We are running, but dependency poisoning is for me. And create the vector.

Ashish Rajan: That’s a good segway into my next question as well, by the way, because I love the example that you gave about the serverless, because I think you have a talk on this as well.

If you don’t mind me, I I’ll plug in the the talk that you’ve had on your serverless one on the show notes as well, but for our audience listening in, I definitely recommend checking out Pawel’s couple of talks that he has done, where he’s kind of elaborated a lot more on these things.

examples With screenshots and [00:20:00] everything as well. So definitely I recommend you guys do that now, since we’re talking about common attack, like dependency poisoning is a great example, but are there any other common attacks that you feel like, obviously you mentioned S3 bucket, you mentioned a dependency poisoning, any other that you recommend that say any pentesters or probably bug bounty hunters who maybe listening to this can look at as the first few avenues to start with.


Pawel Rzepa: There are obviously a lot of such, attacks but Regarding recommendations and detecting the misconfigurations and potential vulnerabilities. I would, strongly suggest to try like Prowler. Which is actually it is scanning your infrastructure and it’s automatically verifies if you have like SQL skews publicly available meaning that any AWS user can just, you know can, can see the message, push the message to this cube [00:21:00] et cetera.

And it detects Any AWS CIS benchmark. Misconfigurations but also even more any this actively supported. So please check it. Another, another thing that you can you, you can check from the cloud security assessment perspective that IAM policies, the identity and access management policies Without understanding how the cloud is used.

Then you cannot do much because you don’t know what permissions should have, which principle, but if you know it, then there’s a two there is called clouds planning. And I really, really liked it because it will verify all the permissions that allow for for example, privilege escalation.

So to give you an example if one of your developer, for example, has permissions to attach any role to alarm the function. So she has, you know, just, just the wildcards in the [00:22:00] resource section. Then such a developer can attach the administrative policy to lump the role. And then.

Execute arbitrary action, like creating new IAM user with that administrator access. So basically this user can can do whatever wants I’ve also discovered I’ve also developed my own tool that is called dumpster diver. And basically its goal is to detect potential secrets in large volume of files.

So if you have multiple files in one of your S3 buckets, but you are not sure if there are any secrets obviously it is quite challenging to scan it manually. But it is possible. For example I was delegating this job to the people in the AWS mechanical service.

I don’t know if you know it, but [00:23:00] in a mechanical Turk, you can delegate actually any job, like, Hey check. Check check the internet to to find me the best price of this particular product. But my task that I met there, of course, and you are giving the price for your task and people are taking it or not.

So to compare the effectiveness of dumpster diver and manual reviewing, I delegate the role that task to verify the five gigabytes of data to I think five people. And they reported me you know, all of them reported different findings. But I could compare, you know, human beings with with the my own to dumpster diver.

So check it out. Soon it will certainly we’ll have new features like the verifying, the regular expressions. Yeah,

Ashish Rajan: no. All good. It’s pretty [00:24:00] good. I think a Prowler, definitely. And I think Kay mentioned here that he’s used pmapper as well. So you mentioned cloudsplanning for IAM

have you had a chance to look at pmapper as well that Kay recommended?

Pawel Rzepa: Yes. However the last support was long time ago and I faced some issues. And I saw in the history that it was reported this issue. But in my opinion that cloud has better reliability and better findings.

Sure. The best way to choose your, your own tool, which is which best works for you is trying both of them. So try both of them, compare the results and choose your choose the better one.

Ashish Rajan: Yep. Right tool for the right job.

Pawel Rzepa: Exactly. Yes.

Ashish Rajan: I’ve got another question from Vineet here. How hybrid cloud environment affect the scope of assessment for pen testers?

Pawel Rzepa: I think the scope assessment well, I would say that that needs to [00:25:00] be specified at the very, very beginning, like that different environment requires different tools. However you can use like scoutsuit, for example, that’s another tool for automatic for detecting, misconfigurations and it works for Azure GCP and AWS as well.

So you can use one tools for detecting such misconfigurations. But however, I would suggest to firstly to do the the threat modeling session at the very beginning before starting testing and then define all the workflows potential other convectors and the entry points.

And to your point a threat model session is alwaysAshish Rajan: good to at least have an understanding of what the basic threats are. Its A great exercise, even if no one has done it before. The next question that I have for you. And I think it’s great that you mentioned Prowler Cloudsplaining dumpster [00:26:00] dive on as well, where you mentioned mechanical turk

what’s a mechanical Turk. And I don’t want to say it’s like a person who wakes up in Turkey .Is that more mechanical Turk?

Pawel Rzepa: Not really. Well then the name came from because long time ago there was like the machine. And somebody said that this machine is that can compete any chess master and actually it was winning with the with a lot of grades Check masters.

So nobody as it was long time ago, , there wasn’t any, , it in that age. But in fact there was a person who was sitting in this machine and said there was a grand master in machine who was playing against all those people. So mechanical turk, Amazon mechanical turk , it’s a service.

Yeah. That, you can simply delegate any task to human beings and they accepted, or depending on how many you are paid for your task.

[00:27:00] Ashish Rajan: Cool. Well, so I guess that’s where air Tasker and stuff came in as well. My next question is more about, we kind of spoke about the tools, but is there a way that pentesters can be on top of these. We’re obviously talking about architecture that just by checking CIS, it’s not a good enough

how do you rinse and repeat kind of thing. How do you keep on top of this kind of thing as a pentester, or even as, someone who has a web app or an application on cloud, how do I be on top of this? Day to day assessment thing, like what would I be doing?

Is there a recommendation that you have for this.

Pawel Rzepa: Well, I would, again, start from threat modelling session and you cant automate it

you have to meet and just discuss very often the threat modelling session is a very Informative, even for the developers, because usually there is no one single person [00:28:00] who knows exactly everything, how this cloud is used and actually what they are using in the cloud.

So then on such meetings those people, who work on a daily basis with their cloud, they. Don’t know about all the things that they, contain and how they are using it. So then if you are looking like on the white board with with all the AWS accounts, are there.

Relations between the each of the AWS account, then you can see where are your weak points. So that for example, would would be good for architectural review, but regarding monitoring. Then you need to know , what are you trying to secure?

So what are your key assets? What to monitor there? Isn’t there, a silver, bullet. That’s okay. You should always monitor this and this and this and that. And then sorry about the [00:29:00] health of it. We we’ve never used it. So.

Regarding, penetration testing services? Well, I don’t have an easy answer. Just do these, and these are, that has because that’s years of experience As well as knowing how things work very often, the applications use a difference technology stack, different protocols so you cannot learn it in just, you know, in one day Also regarding like testing the code is executed outside of the server.

It is run in the Lambda function container. So it would be probably to have a good infrastructure for testing out of bounds vulnerabilities. So for example, in Berkson. You have the bird collaborator for example, Lambda has the vulnerability in your code and such request will go to the bird collaborator, and then you have to [00:30:00] prove that actually you were able to to get out from this Lambda, there is regarding configuration review.

Well, use the tools that I’ve already mentioned. Try it, I don’t, of course, if you have any, any problems doubts, just call me,

Ashish Rajan: definitely reach out to Pawel , well, I was going to say, considering you’ve done this for such a long time. where do you see this going?

Pawel Rzepa: Yeah. So I see a trend that more and more companies start deploying the resources and infrastructure as code. So I think the cloud security assessment will evolve to be more focused on verifying with Terraform or CloudFormation scripts. There are already available tools which may help you to do such assessment of subscripts.

Like for example, Checkov. Which is kind of static analyzes tool for infrastructure as a code and another interesting tool that you should [00:31:00] take a look is SIMTrack which allows you to specify where is. Like regular expressions and using it, you can audit multiple scripts. So imagine that you are going to to do an assessment of hundreds of accounts and all you receive is that Terraform scripts then.

You have to automate it somehow. So some graph and defining who rules, what are you looking for? So for example, if there are any security groups with open ports and then you can using the same graph. You can very easily get in the output, all the publicly available ports in your security group, and that investigate it more.

And and other trends that that probably will happen or it already is happening is using the multi cloud. So. [00:32:00] Then that’s another charge. If your organization is using some services from AWS, some from Azure, some from GCP, then it’s challenging how to ensure security of all those services without complicating the whole process of deployment and using the cloud.

Ashish Rajan: you’ve nailed it on the head with the two trends that you’re noticing, because a lot of the previous guests that have come on the show, they’ve all mentioned this whole thing, that multicloud it’s great idea. And it’s great idea for people who have enough. Experience in the team. But if you don’t have like, say you’re primarily AWS, suddenly you add Azure or GCP, but your team is primarily AWS.

Like they have to learn this whole new technology plus be updated on AWS, but it’s a hard job. It’s not easy. Right.

Pawel Rzepa: I’m telling you, we are talking mostly, I’m talking mostly about AWS. However, also [00:33:00] of course I also had to try that the GCP and Azure and. Some concepts are very different and you can, as an example I will encourage you to watch one of my presentation regarding serverless because they’re I’m comparing the different approaches of each provider regarding the several security.

In the concept, they are the same box. There are many differences from the security point of view and you need to resolve them differently. So it’s not just

Ashish Rajan: bring you back again for, just for the serverless security as well. That’d be awesome. For people can, people who are listening in can vote on whether they should, they should bring back Bovell for.serverless Security as well.

Pawel Rzepa: Well, there was a great story regarding Olin data. So they were they were pretty good and they were trying to they were interviewing people and [00:34:00] One of the interview process was to solve a task. And then you know, some regarding EC2 instances, some the interview we had to write a script that is solving this task, but one of the interviewee and of course, well, if you want to try this, try this solution, they gave those interviewee that EC2 permissions.

To their test AWS account now. They gave this permission without the specifying, what type of instances they can run? How many of them and in what regions. So one of the interviewee uploaded his solution to his github repository. And if you know that the free A GitHub repository is publicly available so soon the articles just took those keys.

They they spin up that largest EC2 instances in every region. [00:35:00] And once they saw it in the all in data, Company, they sat that well, it was Friday. So we said, okay, we will take a look on it after the weekend. And after the weekends, the bill for usage of AWS went to more than $130,000 just for a weekend that they were running it, not just to do The other cars were running the cryptocurrency mining software on those largest instances.

Ashish Rajan: I’m. So with you on this part,Pawel, cause I think people underestimate. It’s literally a data center that you can access to. Right? When you get access to an AWS, it’s not yet you have one machine, it’s a whole data center that you’re going to access to. You can pick up if you don’t have the right controls, you can just basically start doing, I dunno, G4 compute or that’s why there are so many crypto mining incidents that you keep hearing [00:36:00] about.

But that’s a great example by the way. Maybe that’s why github made. The repositories, the free ones as well. Now you can make them private, but it’s the same thing as S3 bucket being public and private people still make it public. And you’re like, do you really think through this before making it public?

Or I find it hilarious, man.

Pawel Rzepa: There’s actually one also one nice feature that we have made. And I didn’t mean, I didn’t know it, but I will, I did a little research and I exposed on my github repository. I exposed some keys to verify what are the next actions of the other curve. And I was really confused that I got the logs.

Six minutes after exposing those keys. So I thought that, Hey, wait. That’s, that’s pretty long for automatic bots, but actually github, once you uploaded it G i thub will i give that five minutes delay of giving [00:37:00] it publicly available. So that’s five minutes slot for. Your actions. So you are notified in the first minute you are notified by AWS.

Your keys are compromised. AWS autumn started automatically, and that’s also quite recent news that they are automatically adding some quarantine policy to those keys. So. The, the article can not well still can do a lot of harm, but not like that they are denied. Actually. I am actions, for example,

Ashish Rajan: wait, so if I got this right, so the acces keys you had put in GitHub, GitHub detected it.

AWS notified you about it. It’s only after five minutes that it was available on the internet for the bots to pick up. Wow. Damn that so, well, there you go. That’s a good sign of collaboration there, I guess.

Pawel Rzepa: Yeah. And it’s collaboration in a very good [00:38:00] direction.

Ashish Rajan: Yeah. Yeah. So that makes me think I’m sort of, are there any interesting attack techniques that you’re seeing?

I mean, I guess either to Dodge, these, or any interesting techniques that you’ve seen in the space recently that you’ve been like, Oh yeah, that’s a good one.

Pawel Rzepa: Oh, yeah, I have one, maybe not so recent, but one of such is the DNS exfiltration. So many people don’t know that the Amazon DNS is using different infrastructure, which is out of your control.

For example, imagine you have the EC2 instance with attached security group, which completely denies any outgoing traffic. Okay. So it’s, it looks like isolated and many people will be sure that there’s no way to execute, rate any data from such instance. However, if an attacker is able to upload the malware to such EC2 instance it can use the [00:39:00] Amazon DNS to exfiltrate some data outside of Amazon network.

Basically if I’m the owner of that domain. My malware on these EC2 instance can put the secret as a sub domain of So although the egress traffic is denied And completely blocked. I can put basic C4 as a basic support in covert secrets. So let’s say it is blah, blah, blah, as a sub domain.

And now the Amazon DNS is trying to resolve this blah, blah, blah, blah, Even if the security group are blocking any outside traffic. So if you know how the DNS works, this blah, blah, will go to my name server out, of course, and I can decode it. So any secret I can you know I can extrude straight from that.

So the recommendation would be use [00:40:00] your own DNS. And then you can simply disabled in the VPC settings to the housemate resolution. This is something that you will find it in the AWS documentation, but how many people are aware of it.

Ashish Rajan: That’s a great, one, man.

I reminded me of another example where the orphan DNS is as well. A lot of people would bring up CloudFront or restart a DNS service and forget about it because they moved on to a new one because that was dev or test or whatever. And then they just leave it.

I think the example was that those DNS, is that available for any other AWS account to kind of hook up and route 53 or whatever. But this is much more cooler than that. , I think I want to change a few more gears as well, because I think we’ve been talking about.

How do you do it? What attack tools you use and what are the attack patterns, but for people who’ve been listening in for this long and I’m like, okay, this is something that I definitely want to be keen on. I want to learn more about this. Where does [00:41:00] someone like this start on this kind of thing?

Pawel Rzepa: My recommend they should is to get your hands dirty. So learn by doing, you can play around with many capture the flag games, for example, and I can recommend you my old one which is called KRKAnalytica

Ashish Rajan: as well.

Pawel Rzepa: Yeah, I don’t want to spoiler but all, it is running on our company infrastructure. And if you have any, problems with solving it, then you can find the workflow of it on my medium blog. But there are other capture the flag games. I should also mention first of all, it is the cloud goat project, which is awesome project.

Basically you are deploying the vulnerable services to your AWS accounts. Again, the full walkthrough of it can be found on my blog and regarding other challenges, [00:42:00] I also recommend to you to check out the flaws and that flaws2 made by Scott Piper. It is also great. And regarding infrastructure as a code the there’s also a great project, which is called TeraGoat.

And. There, you can also try the other two. So there are a lot of free available tools, just, you know instead of watching Netflix, just play around with it, that’s some challenges and also if you want to stay up to date, there are a lot of security researchers on Twitter or LinkedIn following many of them.

And I learned a lot from them. And recently I realized that I learned a lot because I started sharing my knowledge. So. You know, that’s also a good point. You, you know, something learn others, then you will see that you, you [00:43:00] need to dig more into the subject. Someone else then is feeling your knowledge.

Like give it you some feedback that, Hey, there are better ways to do it. You can try this, try that. So really share your knowledge.

Ashish Rajan: I can not agree more on this cause because that’s why the podcast is here as well for me to really share with people. And it’s people like yourself and others, men, I think I learned so much just like the common examples as well, but the more we speak about the more, it sounds like people should have an understanding of how the cloud works as well.

Do they need to have like an, a cloud certification as well? Is that accurate assumption?

Pawel Rzepa: Yep. Well, I would suggest to to everyone to do some certifications because it standardizes your knowledge for sure. And but doesn’t give you in knowledge to perform the cloud security assessment. I doubt it.

[00:44:00] It will give you that the fundamental understanding of concepts, which is actually necessary to, to go farther. So certifications are really great starting point.

Ashish Rajan: to that point certification is great to know what a service can do in a way that they want you to learn. But as a hacker or as a pen test, or as a security assessment or research it’s the same as on-premise as well as better we’ve been taught, or this is how it works.

They’re always talking about positive scenarios that. no one talks about what’s in the middle. Is there a man in the middle or exists the encrypted connection. Like there’s a lot of things, even in that space. Exactly. I love what you said, man. I think certification is great to have an understanding of what that space is, but people who are listening and don’t forget to put your hacker or a pen tester hat on to go, how would I break this service?

If I were to do this all to your point earlier about fuzzing as well, right?

Pawel Rzepa: Yeah. Yeah. So that a [00:45:00] mindset and also Everyone who is insecurity. I think that has such mindset. So everyone is like, sales are talking about how, how great product we have the security guys say, Hey, but this may go wrong.

This may go wrong.

Ashish Rajan: That’s right. I mean, in a way it’s not a bad thing to be a bad person in that context, because you’re just trying to make sure. That the service is safe to be consumed by people. And this makes me think, is there something that people are not talking enough about in a, I guess a cloud security context?

Is there something people aren’t talking about enough?

Pawel Rzepa: I still find too little information about detecting and reacting to attacks. So if you find any detail resources, how to build good incident response process from scratch, then please share it with me. And I think that that should yeah, there should be more [00:46:00] space into this

Ashish Rajan: topic.

Yeah, I agree, man. I think I’ve got a guest coming in next month as well to talk about this because incident response in an on-premise world vs a cloud world where your servers are dynamically increasing to 200. Do you mentioned earlier about the pattern you’re seeing, where you just get Terraform scripts too?

Do a pen test or Hardy, like ready you go over there. And, but then multiply that by two a hundred teraformscript. It’s not just one or two Terraform script because no one just has one Terraform script. I’m like, Oh yeah. It’s a very interesting world, man. I’ve got one final question

could you recommend some certification for beginners?

Pawel Rzepa: Sure. So my path was into the cloud was taking AWS architect associate as the first one that will give you a good understanding. What services are in AWS, how to work with them and how to configure that VPC, [00:47:00] how the networks were there.

Really, really good. Give you the good, fundamental, basic understanding. And then I went through the security path, so I made the AWS security specialist certificate. And also I found it Really nice because I learned a lot about some concepts that I’ve never focus before.

So those two make those two and yeah, you will be, you will be good. You will be satisfied.

Ashish Rajan: And would you also add if I may just focus on one cloud to begin with? I don’t think we’re doing all the clouds.

Pawel Rzepa: Yeah. If you have time do do the same for every provider and you will be even better.

Ashish Rajan: Yeah. Just copy and paste the same method for each cloud provider.

Or pick one and just deep dive into it and become that person as well. So this was really great, man. For people who want to reach out to you for American food recipes, [00:48:00] I’m sorry for knowing more about how to do security testing in AWS, where can they find you on social media?

Pawel Rzepa: On Twitter and LinkedIn, I also write some articles on my medium blog. So feel free to reach me. I would be very happy to answer you. Maybe not so fast just in trying to, you know, effectively manage by time, but for sure, I will answer you.

Ashish Rajan: Oh, yeah. And I was going to say, and on all those social media, is that is your handle still Pawel Rzepa?

Pawel Rzepa: Not really. It’s so R Z E S K Y.

Ashish Rajan: Yeah. And I will add in the show notes as well, so people can easily find you as well. And. Dude, thank you so much for taking the time. And I do, I do appreciate you staying up late for me, for the show and for all the audience members as well. So thank you so much for taking the time out.

I really appreciate it. And I think the audience did as well with all [00:49:00] the questions coming in. So I’m super happy. And I’m looking forward to bringing you back again, man.

Pawel Rzepa: Thank you very much for having me. I really enjoyed this

Ashish Rajan: time. Oh, thank you so much. All right. Everyone. We’ll see you in the next episode.

Take care.

No items found.