Cool, yet simple finding from the DataDog security team where calls to an undocument iamadmin service would also not appear in CloudTrail logs but could reproduce the functionality of several standard IAM service methods.
The DataDog team found the undocumented API just by scanning what APIs the cloud console was using and noted the iamadmin one as unfamiliar. Upon trying to determine if it was just calling the normal IAM service to fulfill the requests they realized the requests were not being logged at all. Its a solid finding, and one of those vulnerabilities that is a vulnerability because it defeats a large part of the entire purpose of the CloudTrail service.
Two vulnerabilities, the first an insecure activity is exposed that allows other applications to automatically install any application on the Galaxy Store, the secondis a filter bypass which can lead to navigating the CloudGame webview to an untrusted domain.
The first issue basically seems like an insecure feature. An activity is exposed, it will read properties from the intent such as GUID, directInstall, and directOpen then if directInstall is true, it’ll install the application specified by the GUID and if directOpen is true, it will open the app after installing.
Ideally this sort of functionality should be using a whitelist of acceptable applications that can invoke the activity, or perhaps using some sort of signing mechanism so that only Samsung trusted sources can generate a valid signature to use it, neither mitigation is in place here.
The second vulnerability is just a filter bypass, the Cloud Game webview can be opened using an intent://cloudgamewith some expected params that the write-up documents. The key thing is that the host, provided through the monitoringHost parameter is supposed to be limited to player.glb.samsung-gamelauncher.com. This filter can be bypassed in a pretty classic way though as it only ensures the host starts with the expected domain, so a domain like player.glb.samsung-gamelauncher.com.attacker.com would also be valid.
NCC Group does not document the damage that could be done with this vulnerability. Often these webviews will have some extra interfaces added to them to communicate with the host application and device, but its not mentioned in the report.
A cool bug that can inject a new user with controlled SSH key into a compute instance and the request doing this can be reached via a GET request with no anti-CSRF token.
The bug impacts the “SSH-In-Browser” feature of GCP that allows users to SSH into an instance using their browser. It has a feature that allows you to change your Linux username, to do so it creates whatever username you specify, and generates an SSH key for it adding it to the authorized keys using a request like the following:
https://ssh.cloud.google.com/v2/ssh/projects/{PROJECT-NAME}/zones/{INSTANCE-ZONE}/instances/{INSTANCE-NAME}?newLinuxUsername={USERNAME}
That on its own feels like a bit of a security concern, but without being able to browse the generated SSH keys an attacker couldn’t do much besides create new accounts.
Digging into this though the author found that if they had a username with a : in it, the part after the colon would be included as part of the public key for the account. So triggering the creation of a username like attacker:{public key here}\r\n. Would result in the addition of the user attacker and it would add their public key to the authorized key file.
The trailing \r\n was included as the generated public key would still be appended to their “username” so adding a new line meant the entry in authorized_keys would parse their injected key correctly. Once the attack lands they can then SSH into the instance using their injected key.
An IDOR style issue allowing access to the data plane of a Azure Cognitive Search instance even if that instance was isolated from the internet.
The vulnerably starts with the addition of a “Allow access from Portal” toggle which was intended to allow the Azure Cognitive Search instance’s data plane to be accessible from the Azure portal regardless of the network restrictions on the instance. The authors dug into how this feature worked and what they found was basically a proxy service running on the Azure Portal. This interface would take in various pieces of information like those needed to actually specify the instance to query, it also took in an API key, but did not sufficiently validate the key. It would ensure the key was still valid, and was issued to the proper audience (the Azure Resource Manager API). It did not check if the key was issued within the same tenant, or provided real permissions to the data. So anyone could use their own token to access the data of any tenant.
This would require knowing specific information about the ACS instance you’d like to reach which can be challenging, but the fact that basically anyone could access any other’s tenant data even when it seemed that tenant was completely isolated is an issue.