Search This Blog
Powered by Blogger.

Blog Archive

Labels

About Me

Load More
Trendy Right Now

Popular Posts

Showing posts with label AWS Credentials. Show all posts
User Privacy
AWS Credentials Mobile Security Spyware Stalkerware User Privacy

Amazon Faces Criticism For Still Hosting Stalkerware Victims' Data

 

Amazon is drawing fire for hosting data from the Cocospy, Spyic, and Spyzie apps weeks after being notified of the problem, as the spyware firms continue to upload sensitive phone data of 3.1 million users to Amazon Web Services (AWS) servers. 

Last month on February 20, threat analysts at TechCrunch, an American global news outlet, notified Amazon of the stalkerware-hosted data, including exact storage bucket information where the stolen data from victims' phones was stored. However, as of mid-March, no firm steps have been taken to disable the hosting servers. 

In response, AWS thanked TechCrunch for the tip and sent a link to its abuse report form. In response to this statement, Ryan, the AWS spokesperson stated, "AWS responded by requesting specific technical evidence through its abuse reporting form to investigate the claims. TechCrunch declined to provide this evidence or submit an abuse report.”

The Android apps Cocospy, Spyic, and Spyzie share identical source code and a security vulnerability that can be easily exploited. The flaw abuses poorly secured servers used by the apps, allowing external access to exfiltrated data. The servers employed by the apps have Chinese origins and store data on Cloudflare and AWS infrastructure.

On March 10, TechCrunch notified Amazon that the Spyzie app was also uploading stolen data to its own Amazon bucket. According to Amazon, AWS responds to complaints of abuse and has stringent acceptable usage guidelines. The company's procedural reaction, however, has come under fire for taking too long to take action regarding hosting stolen data.

Ryan clarified that AWS responded quickly and made repeated requests for the technical data required to conduct the investigation, which TechCrunch declined. He went on to say: "AWS's request to submit the findings through its publicly available abuse reporting channel was questioned by the outlet, which declined to provide the requested technical data.” 

Stalkerware thrives on direct downloads, despite being banned from major app stores like Google Play and Apple's App Store. While some sellers say that the apps are for legal purposes, their capabilities are frequently utilised in ways that breach privacy regulations.
Read more »
whoAMI
Amazon cloud AWS Credentials Cyber Security Data Safety whoAMI

whoAMI Name Assaults Can Compromise AWS Accounts to Malicious Code Execution

 

Datadog Security Labs researchers developed a new name confusion attack technique known as whoAMI, which allows threat actors to execute arbitrary code within an Amazon Web Services (AWS) account by uploading an Amazon Machine Image (AMI) with a specified name. 

The researchers warn that, at scale, this assault can impact thousands of AWS accounts, with approximately 1% of organisations believed to be vulnerable. An Amazon Machine Image (AMI) is a virtual machine image used to start Elastic Compute Cloud (EC2) instances. Users can use the AWS API to search for the latest version of an AMI or provide it by ID. 

Datadog Security Labs stated that anyone can publish an AMI to the Community AMI catalogue; in order to verify whether a user searching the catalogue for an AMI ID will receive an official AMI rather than one published by a malicious actor, he can specify the owner attribute. 

When searching for AMIs, using the owner attribute may ensure that results are from verified sources such as Amazon or trustworthy providers. If the owners property is not included in an AMI search, an attacker can publish a malicious AMI with a recent date, making it the first result in automated queries. The attack happens when a victim uses the name filter without specifying the owner, owner-alias, or owner-id criteria, and retrieves the most recently generated image. 

“To exploit this configuration, an attacker can create a malicious AMI with a name that matches the above pattern and that is newer than any other AMIs that also match the pattern. The attacker can then either make the AMI public or privately share it with the targeted AWS account.” reads the advisory published by the company. 

The researchers published a video proof-of-concept of the assault and developed an AMI with a C2 backdoor preinstalled (attacker AWS Account ID: 864899841852, victim AWS Account ID: 438465165216). 

“This research demonstrated the existence and potential impact of a name confusion attack targeting AWS’s community AMI catalog. Though the vulnerable components fall on the customer side of the shared responsibility model, there are now controls in place to help you prevent and/or detect this vulnerability in your environments and code,” the report concluded. “Since we initially shared our findings with AWS, they have released Allowed AMIs, an excellent new guardrail that can be used by all AWS customers to prevent the whoAMI attack from succeeding, and we strongly encourage adoption of this control. This is really great work by the EC2 team!” 

As of November last year, HashiCorp rectified the flaw in terraform-aws-provider 5.77, which now warns when "most_recent=true" is used without an owner filter. This will become an error in version 6.0.
Read more »
User Privacy
AWS Credentials Data Breach Data Leak Data Sale User Privacy

Misconfigured AWS Cloud Instances Lead to Sensitive Data Breaches

 

Misconfigured cloud instances have once again enabled cybercriminals to steal sensitive data, including credentials, API keys, and proprietary source code. This time, numerous Amazon Web Services (AWS) users fell victim, highlighting a lack of understanding regarding the shared responsibility model in cloud infrastructure.

Discovery of Vulnerabilities

Independent security researchers Noam Rotem and Ran Loncar uncovered open flaws in public websites in August 2024. These flaws could be exploited to access sensitive customer data, infrastructure credentials, and proprietary source code.

Data Exploitation and Sale on Telegram

Further investigation revealed that French-speaking threat actors, potentially linked to hacker groups Nemesis and ShinyHunters, scanned "millions of websites" for vulnerabilities. By exploiting these flaws, they harvested an array of sensitive information, including:

  • AWS customer keys and secrets
  • Database credentials and data
  • Git repository data and source code
  • SMTP credentials for email sending
  • API keys for services like Twilio, Binance, and SendGrid
  • SSH credentials
  • Cryptocurrency-related keys and mnemonics
  • Other sensitive access data

The stolen data was sold via a private Telegram channel, reportedly earning "hundreds of euros per breach." Investigators noted that the perpetrators might need the funds for legal defense once apprehended.

Investigation and Response

Rotem and Loncar traced the incident to specific individuals and reported their findings to Israel's Cyber Directorate and AWS Security. The researchers stated: "Our investigation has identified the names and contact information of several individuals behind this incident. This could help in further actions against the perpetrators."

AWS promptly took action to mitigate risks and emphasized that the vulnerability stemmed from user-side misconfigurations rather than AWS systems: "The AWS Security team emphasized that this operation does not pose a security issue for AWS, but rather is on the customer side of the shared responsibility model – a statement we fully agree with," vpnMentor reported.

The Shared Responsibility Model

The shared responsibility model in cloud computing divides security responsibilities between the cloud service provider and the customer. AWS ensures the security of its infrastructure, while customers are responsible for securely configuring and managing their data and applications.

Irony in Misconfiguration

Ironically, the stolen data was discovered in an unprotected AWS S3 bucket—another misconfiguration. According to the researchers: "The data collected from the victims was stored in an S3 bucket, which was left open due to a misconfiguration by the owner. The S3 bucket was used as a 'shared disk' between the members of the attack group, based on the source code of the tools they used."

Lessons for Cloud Security

Cybersecurity experts emphasize that cloud misconfigurations remain a leading cause of data breaches. Organizations must take proactive steps to secure their cloud environments:

  • Implement strict access controls and regular audits of cloud configurations.
  • Use tools to detect misconfigurations and vulnerabilities in real-time.
  • Educate employees about the shared responsibility model and best practices for cloud security.

This incident underscores the critical need for customers to take their share of responsibility in safeguarding sensitive data and highlights the risks of negligence in cloud security practices.

Read more »
Subscribe to: Posts (Atom)