This week’s news brought to you by Teleport
This week, we are kicking off with a few vulnerabilities that security Researcher and Cloud Security Community members have worked hard to dig out for us, so that we are aware of them and can ensure we take appropriate steps to mitigate them
- Mohammed Saqeeb Shariff and Asif Khan recently found and reported a Threat evasion technique to AWS and were allowed to publicly share their findings. The evasion technique allows any privileged user with MFA enforcement and no permission to generate access keys to perform sensitive actions like deleting, creating and launching services using Session tokens and without the need for entering MFA. They were able to achieve this using Session Tokens generated and assigned by AWS to their AWS CloudShell service. Temporary Session tokens generated from AWS credentials or Access Keys are known to not appear anywhere on the AWS Console or CLI. This technique can be used by threat actors to maintain presence without detection in the AWS Accounts they have tokens for. More details about this evasion technique can be found here. The best way to mitigate this is to ensure AWS Cloudshell access is only given to users who have the requirement and the least privilege principle is followed. You can read more about their findings here
- On the topic of AWS AWS Security Hub has released 5 new controls for its Foundational Security Best Practices standard (FSBP) to enhance your Cloud Security Posture Management (CSPM). These controls conduct fully automatic checks against security best practices for Amazon CloudFront, Amazon Elastic Container Registry (ECR), Amazon Elastic Load Balancer (ELB), and Amazon Simple Storage Service (S3). If you have Security Hub set to automatically enable new controls and are already using AWS Foundational Security Best Practices, these controls are enabled by default. Read more about the 5 new controls here.
- Last week, we shared all things Spring4shell – what it is and what does it mean for us? If you are not across Spring4shell, i do recommend checking out our episode from last week. Now that you are all caught up, or you thought you were, researchers from Snyk have reported similar exploits for Glassfish and Payara that leverage the same issue in Spring, but with a different payload. Glassfish and Payara if you are not familiar are open-source platform application servers. Snyk reported their findings to the Payara team which helped them confirm their own analysis that certain configurations of Payara could be vulnerable. Snyk rightly points out that this is not a new vulnerability but another example of how to exploit the same Spring4shell vulnerability on a different server and the best thing to do as we shared last week is to update your Spring framework to the latest version. You can read Snyk’s blog and findings here.
- Trend Micro Threat Research team have also reported they have observed active exploitation of the Spring4Shell vulnerability which allows malicious actors to weaponize and execute the Mirai botnet malware. Now Mirai is a malware that turns networked devices running Linux into remotely controlled bots that can be used as part of a botnet in large-scale network attacks. You can read more about their findings here.
- Are you familiar with Amazon RDS? its Amazon Relational Database Service (RDS) – a managed database service that supports several different database engines such as MariaDB, MySQL, and PostgreSQL. Lightspin who we covered last week for their launch of recon.cloud have reported that they obtained credentials to an internal AWS service by exploiting a local file read vulnerability on the RDS EC2 instance using the log_fdw (foreign data wrapper) extension. The foreign data wrapper is an extension available in PostgreSQL that allows you to access a table or schema in one database from another. Lightspin reported this vulnerability to AWS, they issued a patch in a few days and confirmed that no customers were affected. Read about their findings here.
- Cloud Security Alliance has released the SaaS Security and Misconfigurations Report. According to them SaaS misconfigurations are leading to security incidents – which is a common trend, we continue to see that misconfigurations are still a major contributor to security incidents. They shared that at least 43 percent of organizations report that they have dealt with one or more security incidents because of a SaaS misconfiguration.The leading causes of SaaS misconfigurations are lack of visibility into changes into the SaaS security settings (34%) and too many departments with access to SaaS security settings (35%). You can access this report here