Researchers have found a way to detect and circumvent Honeytoken keys in a number of Amazon services.

In the modern information security paradigm for the masses, the opinion is firmly entrenched that cyber security is expensive, difficult, and virtually impossible for the average user. So if you want to fully protect your data and personal information, get yourself an account with Google or Amazon, nail it to identify the owner and periodically check the alarm alerts that a large and strong company has stopped another login attempt.

But people who understand information security always knew that cloud services are much more vulnerable than a separate workstation. Indeed, in the case of a force majeure PC, you can physically restrict access to the network, and there already begins the race for changing turnouts and passwords in all the attacked directions. The cloud infrastructure is huge, often decentralized, and data from several clients can be stored on the same physical medium, or vice versa, the data of one client is spread across five continents, and only an account can unite them.
')
In short, when the Internet was relatively fresh and young (as it was in 2003), then information security specialists took a close look at the buffer overflow protection system of 1997, and released the technology that we now call Honeytoken or Canarytoken. And for fifteen years they have been working properly (and are still working), only the latest study says that instead of the last line of defense in a number of AWS services, Honeytoken turned into a gaping hole in information security due to the implementation on the Amazon side.

What is Honeytoken?

Honeytoken, like its ideological progenitor in the stack overflow protection system, uses a “warn, not prevent” approach. In fact, Honeytoken is a bait for intruders, which is left under the guise of valuable information and can be presented in the form of, for example, links. The most obvious Honeytoken in the practice of ordinary users - a link-alarm, hidden in the letter with the title "data on bank accounts" or "my accounts." The principle is also simple: as soon as the attacker covet the information that Honeytoken pretends to be, the latter sends a notification to the owner / administrator that the security perimeter has been violated.

In the perimeter itself, Honeytoken obviously does not include: in the classical form, this is a banal dummy, which is already inside the perimeter and fulfills the same role that the dying canaries in the miners' faces played in - the danger warning.


And here is the progenitor of technology

Such "signaling systems" are now fairly common and are used to alert personal account holders and prior to AWS security breach notification. At the same time, there is no single standard Honeytoken - it could be anything. For example, several special dead boxes are added to the lists of e-mail addresses of customers, the appearance of a mailing list on which will indicate that the entire database has been drained.

What is a vulnerability found in AWS

Amazon Web Services is actively using Honeytokens to receive alerts about the perimeter violation of the cloud security service. Amazon's “Canaries” are fake account access keys. For all its simplicity, this tool is extremely important: cloud services are subject to constant hacking attempts and other attacks. The mere fact of owning knowledge about the “breakthrough” of the AWS cybersecurity perimeter in one direction is half the battle for Amazon engineers.

Yesterday, October 2, 2018, experts from Rhino Security Labs published an extremely unpleasant study, the essence of which is expressed by the following statement: Honeytokens Amazon Web Services can be circumvented without disturbing the cloud signaling system. This gives attackers the opportunity to quietly "enter", "take" what they need and also quietly "leave."

The entire Honeytokes AWS architecture is based on the use of fake keys in conjunction with CloudTrail , which also maintains activity logs. But in the free access in the userguide Amazon has a whole list of addresses and services that do not support CloudTrail. In fact, this means that any requests towards these services, including through the API, are not recorded anywhere. In this case, the reverse message with access error Amazon returns with the ARN .

Next, researchers from Rhino Security knocked AWS AppStream through the DescribeFleets API and obtained the following information about the test account:



Then, using it, the attacker extracts information about the IAM user / role of the following plan:
IAM User:
arn:aws:iam::111111111111:user/the-path/TheUserName

IAM Role:
arn:aws:iam::111111111111:role/the-path/TheRoleName/TheSessionName

As a result, thanks to the return of the ARN and the obtained IAM user / role data, the experts were able to compromise the Honeytokes bait keys on the listed services through the parsing.

Countermeasures

The found path puts at risk not only AWS, but also developers of popular honeytoken-systems for Amazon systems, such as CanaryToken and SpaceCrab . Both developers have been notified and take all possible measures to eliminate the problem.

Also, experts from Rhino Security have published a PoC script on GitHub , which will check if the AWS key provided to you is not a token, since not all configurations have been updated yet.

Amazon reaction

Amazon replied to the report from Rhino Security Labs that the ARN is not sensitive information, CloudTrain works (and does not work) where needed, and there is no problem as such.