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 established 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 in with respect to identifying the owner and periodically check the alarm alerts that a large and strong company has stopped another login attempt.
But people who know about information security always knew: 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 media, or vice versa, data from one client is spread across five continents, and only the account can unite them.
In short, when the Internet was relatively fresh and young (as it was in 2003), the then information security specialists took a close look at the 1997 buffer overflow protection system and released the technology that we now callHoneytoken or Canarytoken. And they have been working for fifteen years (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 because of 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 a 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 an alert 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 quite common and are used to alert owners of personal accounts 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. This tool, for all its simplicity, is extremely important: cloud services are subject to constant hacking attempts and other attacks. The very 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 publishedAn 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 registered anywhere. In this case, the return 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 retrieves the following plan 's IAM user / role information : Finally, thanks to the return of ARN and the IAM data received the experts were able to compromise the Honeytokes bait keys on the listed services through parsing.
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 that will check if the AWS key provided to you is not a token, since not all configurations have been updated yet.
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.