Treasure Troves and Intel Speculative Execution

The January 3, 2018 Virtualization and Cloud Security Podcast covered two very important issues: the treasure troves used as bases for attacks and the Intel CPU speculative execution bug. The former allows people to access critical cloud and internal resources, while the later allows elevation of privileges to see and act upon data within the CPU itself. Both can be considered treasure troves of data that a bad actor would love to have and act upon. How do you defend yourself?

Veeam Field Product Manager Michael White and I delved into both these issues on the Virtualization and Cloud Security Podcast. Have a listen.

Speculative execution is a way to preload the CPU cache with data and instructions. This keeps the CPU full and working efficiently. If the CPU were not full, there would be performance degradations from a nanosecond to several orders of magnitude. This is crucial to a well-run system. However, the CPU can access data that is outside the security context of the process running. That data can be seen, copied, and exfiltrated. This elevation of privilege attack would allow a bad actor to access memory that was not theirs—memory that could include user credentials, encryption keys, and other data. There are two forms of this attack: one that reads data, and one that forces data to be loaded from privileged locations in memory. Neither of these is a good thing.

The bug is serious enough that major clouds are starting their shutdown of virtual machines and patching schedules. This means that if you do not have mulitzone cloud environments, you may wish to plan your own business continuity approaches within the cloud to make use of multiple zones. Clouds like Amazon, SoftLayer, and others do not make use of vMotion or live migration, so they shut down virtual machines, patch hosts, and reboot. The downtime could be minutes to hours. Business continuity is in the customers’ hands.

You can find much more on the attacks by going to If you cannot reach that site, here are some other resources of interest:

The treasure trove, however, is a totally different style of attack. Instead of looking within the operating system, it is possible to look in data repositories for critical information, such as API keys for Amazon or Azure. Last year alone, the repositories netted criminals stolen resources within clouds, stolen data, and access to credentials. Criminals no longer do much by hand, as is seen by those who troll GitHub for API keys, launch virtual machines within Azure or AWS, and run Bitcoin or other, more malicious sites. These stolen assets add up. Some have been hit with $100K expenses in just one day.

This reminds me of The Cuckoo’s Egg, written by Clifford Stoll, who discovered a hacking ring from a 72-cent error in accounting. This means to find out if your resources are being stolen, you need to pay close attention to your accounting. At the moment, it may be the fastest way to learn there is an issue and shut down the offending virtual machines or tools in use. That is crucial. If you wait a month, your bill could be ten to one hundred times what you expected.

The solution is to watch what you place in repositories such as S3 and GitHub, among others. You can do this programmatically or using third-party tools. There is the Hooks subproject of to aid in a programmatic approach for GitHub, as well as HyTrust CloudAdvisor for a third-party tool. Being able to inspect your data repositories for sensitive data and treasure troves will be extremely useful.

2018 looks to be an interesting year, a year where data management becomes crucial—whether that data management is within each system or within major cloud repositories.

Posted in SecurityTagged , , ,

Leave a Reply

Be the First to Comment!