Threat researchers discovered a new security threat to a recently added functionality in Amazon Web Services (AWS). The attack vector is related to the “Elastic IP transfer” capability of AWS’ Virtual Private Cloud, which was introduced in October 2022. The transfer is completely API-Driven that includes a two-step process between AWS accounts, the source account, and the transfer accounts. This functionality makes transferring Elastic IP (EIP) addresses from one AWS account to another easier. However, threat actors may use Elastic IP transfer to compromise an IP address. Threat actors can launch various attacks, depending on the amount of trust and dependence others have in relation to the hijacked IP highlighting the need to quickly remediate the vulnerability.
As is often the case with valuable new features, threat actors with the right credentials and permissions can potentially misuse features to inflict harm.
What Malicious Elastic IP Transfers Look Like?
Assuming threat actors have the right permissions to the transfer process, there are three possible scenarios.
- Transfer Non-Associated EIP – This is the most simplistic instance, but it illustrates the core concept. EIPs are associated, but organizations keep disassociated EIP because of unmanaged environments keeping unused resources, or because keeping EIPs previously used for later use is easier than updating any associated resources, including DNS “A” records or all the organizational firewall rules. Threat actors only need to enable the EIP transfers, then accept them in another account before any security tool or worker detects and revokes the transfers (which is possible using the DisableAddressTransfer API before being accepted to the transfer accounts), and the IP addresses are theirs.
- Disassociate EIP from Stopped Instance or an Unattached Network Interface & Transfer the EIP – If the EIPs are already associated, they need to be disassociated before they can be transferred. AWS charges a small hourly fee for associating EIPs with halted instances or disconnected network interfaces. Having standby EIPs as part of the disaster recovery plans is common practice when recovering from failures by turning the instance up. Threat actors disassociate EIPs from instance/network interfaces and enable the EIPs’ transfers. This scenario gives threat actors an advantage because attacked organizations may be unaware of the transfers for a long time. This requires additional IAM permissions, which users and threat actors must have.
- Disassociate EIP from a Running Instance & Transfer the EIP – IF EIPs are disassociated from running instances or active ENI, the API and IAM are the same as in the previous scenario and no extra permissions are required. This scenario is more likely to be recognized than the others because victims may rapidly notice anything wrong with the running instances and can potentially cause denial of service within systems or applications. As in Scenario 2, threat actors need to disconnect EIPs from running instances and enable the EIP transfers. People wonder what happens in terms of IP addressing when EIPs are removed from active resources. There are two possibilities:
-
- If instances or ENIs have local or subnet properties set that dynamic IP addresses need to be automatically applied, removing EIPs will result in the automatic substitution of different public IP addresses within seconds.
- Nothing will happen if automatic assignment properties are not set. The removal of EIPs can result in resources having no public IPs.
What Permissions Do Threat Actors Need on Victims’ Account for the Attack?
Threat actors will need to view existing elastic IP addresses and their status (if already associated with other computing resources). Threat actors will need to activate Elastic IP address transfer. Threat actors’ attached IAM (identify and Access Management) policy need to include the following actions: ec2:DescribeAddress on all IP addresses (“*” on resource element) and ec2:EnableAddressTransfer on the elastic IP address threat actors want to transfer. To transfer already EIPs, threat actors need to use the ec2:DisassociateAddress action on the elastic IP addresses and network interfaces IP addresses are attached to disassociate the address. Threat actors will need two or three API permissions to exploit the functionality.
What Can Threat Actors Do After Successful IP Transfers?
Despite greater awareness of the risks associated with IP-address-based security, companies continue to rely significantly on IP addresses to authenticate and verify the identity of 3rd party services, servers, and users. The following are some frequent potential attacks that can take advantage of gaining control of IP addresses when security controls rely on IP addresses for security. These are just a few instances where there are various potential attacks, and they all depend on how much faith and dependence others have in the hijacked IP.
- If victims set security groups with ingress rules that contained the transferred IP addresses that previously belonged to them in a public VPC network, threat actors can communicate with resources through the security groups.
- If there are allowed rules on specific elastic IP addresses that have been moved into victims’ other external firewalls, threat actors can connect with network endpoints identified behind the firewalls. Threat actors, for example, can initiate connections to databases hosted on victims’ on-premises infrastructures that are behind the companies’ security systems.
- Threat actors can impersonate the previous owners’ public network presence if there are DNS “A” entries pointing to the Elastic IP addresses. For example, threat actors can exploit it by hosting malicious web servers beneath legitimate victims’ domains and using them for malicious purposes including phishing attacks. However, because of mismatched server certificates, HTTPS (TLS) connections will fail in some circumstances, and modern browsers will normally prevent all but the most irresponsible customer from connecting.
- Malicious actions include C&C (command and control) servers using Elastic IP addresses for malware campaigns that can go under the defensive tools’ radar.
- In circumstances when the Elastic IP is separated from a functioning endpoint and transferred, threat actors can cause denial of service (DOS) to victims’ public services by interacting with unresponsive IP addresses.
Threat actors will need at least two or three API permissions to use the feature for malicious intentions. There are various actions companies using Elastic IP transfer can use to mitigate the threat.
- Using AWS’ “service control policies” to apply the principles of least privilege.
- Automated detection and response using EnableAddressTransfer API
- Using AWS’ BYOIP (bring your own IP) feature
- Reverse DNS protections
The EIP transfer feature is beneficial, however, it introduces a new attack dimension to AWS that previously didn’t exist. Stealing static public IP addresses can have significant impacts on companies, putting not just companies’ assets but also companies’ clients at risk. That’s why it’s important for companies to always remain vigilant on the current threat landscape and keep their employees updated on new attack vectors emerging. At SpearTip, our certified engineers are continuously working 24/7/365 at our Security Operations Center monitoring companies’ data networks for potential new cyberattacks and ready to respond to incidents at a moment’s notice. Our remediation experts focus on restoring companies’ operations, reclaiming their networks by isolating malware, and recovering business-critical assets. Our ShadowSpear Platform, an integrable managed detection response tool, delivers a cloud-based solution collecting endpoint logs and detecting sophisticated and advanced cyber threats with comprehensive insights.
If your company is experiencing a breach, call our Security Operations Centers at 833.997.7327 to speak directly with an engineer.
