This blogpost contains summaries of talks from this year’s TROOPERS18 Defense & Management Track.

All Your Cloud Are Belong to Us

The talk “All Your Cloud Belong Are Belong to Us” was held by Nate Warfield, who is a Senior Security Program Manager for the Microsoft Security Response Center (MSRC).
Before Microsoft he worked as a network engineer about 18 years and 10 of this for a large amount of cell phone companies.
Nate gives an overview about the state of the cloud solution provided by Microsoft, Azure, and how he hunts vulnerabilities in this environment.
Finally he concludes that the giving up your infrastructure to the cloud doesn’t mean that you give up your responsibility.

Summary

Because he comes from the network branch, he first compare traditional networking to the cloud networking.
In traditional networking are many rules and methods to control whats necessary to have, what can be restricted, what is exposed externally,
who is responsible for what and who take care. In the newer cloud networking many of these are missing.
The main difference is that in cloud networking every VM is exposed directly to internet. They general deploy a predefined firewall configuration and have a decentralized patch management.
He ends with the item that there are many NoSQL databases open to the internet.
Whereby all NoSQL solutions write in their security manuals that they are not intended for internet exposure.
How ever many of NoSQL instances are globally reachable and until now there are 100.000 systems compromised.

Nate shows how he hunts for vulnerable systems in Microsoft Azure.
Because of the high number of IPs in Azure (almost 1.6 million) and variety of different ports each NoSQL solution runs, port scans are very slow.
So he uses Shodan to identify these compromised machines, because it provides several advantages over a conventional port scan.
Therefore it provides metadata for each IP, the DB names are indexed and searchable and finally he can export the result in JSON to use the data for automated hunting. Also, he experienced that Shodan data matches internal Azure data up to an accuracy of 98-99%.
Usually you can build you own virtual machine in Azure or you can use the images with pre-installed software and configuration settings including firewall rules.
These images can also be submitted by third-party vendors. In Azure almost the half of all images from third-party vendors available exposes additional ports by default.
Nate wrote a python script to identify such database systems, available on his github.
Shodan can also be used to identify vulnerable software.
Nate showed how he identify all IPs of system which have an exim mail version installed which is vulnerable to remote code execution (CVE-2018-6789).
So he identified over 1000 virtual machines within 5 minutes.
One other problem in third-party images are they occasionally contain default passwords. These passwords are not always changed.

In the common scenario, Infrastructure as a Service (IaaS), the cloud hoster only take care of the virtualization, servers, attached storage and the network.
Which means that the operating system, the stored data and the installed software is in your responsibility.
A big misbelief is that if the systems were hosted by Microsoft and Microsoft will patch them.
That’s a big issue because some third-party images are created up to 700 days ago and so they already contain at deployment more than two years of vulnerabilities.

Conclusions

So Nate showed us easy ways to identify vulnerable cloud systems and the misbelief many cloud customers.
Putting your environment to the cloud doesn’t mean immediately that you give up your responsibility to your cloud hoster.
There are models for these but the most common provides only the hardware and the network.
Platform as as Service (PaaS) and Software as a Service (SaaS) gives you the opportunity to give up more or all responsibility.
At the End he gives some advices how to handle newly deployed virtual machines:

Update your IaaS VMs immediately after deployment
Review firewall settings before deployment
for sensitive roles consider building your IaaS Image
Better visibility into out-of-the-box IaaS VM security
- Age of IaaS VM image
- Default firewall policies
- Version of daemons/services

Blue Team Sprint: Let’s fix these 3 things on Monday by Mattew Domko and Jordan Salyer

A sprint is an event where developers have to reach a goal in a fixed amount of time. The idea behind a sprint is that almost every company is short on money when it comes to developing and especially security. With that in mind, the speakers thought about how to get inexpensive network monitoring and application control to work.

The speakers use Bropy3 and AppLocker to secure the clients, the network and build an IDS (Intrusion Detection System).

Bro is a network traffic analyzer which writes its results into a logfile. Bropy generate baselines off the bro output. This baseline, basically a whitelist, can be used to monitor the network traffic and alert the administrator if anomalous network traffic is found. This construction is a very basic, but easy to setup and inexpensive IDS. The baseline can even be used to generate firewall rules.

Microsoft AppLocker restricts programs from executing on client systems. It is included in Windows and can be run in several modes to generate policies and then enforce them. This prevent users to run malicious executables. The rules that can be used are publisher signature, hash or path of the executable.

Elastic stack is a software stack containing Elastic Search, Logstash and Kibana. Elastic Search indexes the logfiles, Logstash normalizes them and Kibana makes charts. With the Elastic stack AppLocker logs as well as Bropy3 data can be reviewed on a central dashboard allowing administrators to see what was tried to execute on a client computer.

Conclusions

Securing the network and the clients against basic attacks isn’t as hard and expensive as one might think. With the introduced tools basic monitoring and policy enforcement is possible with minimum resources; also the slides provide many C&P commands that get you up and running with a basic setup!

Language of Security – Sharing Knowledge without spreading FUD

“Language of Security – Sharing Knowledge without spreading FUD” was a talk by Dr. Kelley Misata and Diana Kelley at Troopers 2018 about how to communicate security topics without confusing or scaring non-experts.

Kelley is a former Director of Communications at Tor and current Executive Director of OISF and Suricata. She started her career in marketing, but got interested in information security after experiencing cyberstalking and did a PhD in this area. Currently, she is setting up a new non-profit called Sightline Security, which helps other non-profits with improving their information security. Diana got started in the area of information security on the DARPA net and managed global networks in the 90s. She is co-author of the book “Cryptographic Libraries for Developers” and is currently working as Cybersecurity Field CTO at Microsoft.

The reason for Kelley and Diana giving this talk is they are tired of the FUD (Fear, Uncertainty and Doubt) surrounding information security. They want to raise awareness about security issues, but without scaring and confusing the non-technical audience, which happens quite often in the media. Further, they don’t want the topics to be too much dumbed down, but instead communicated better way that a non-technical person can comprehend.

One main problem here are technical terms: Without the background in information security, they might have the wrong annotation to people not used to them. For us, they are used so common that we don’t even realize a non-technical person might not understand them. For example, if the news announce that Microsoft has released patches for 15 critical bugs in march patch Tuesday update, non-technical people might think of patches one can put on jackets – an association that does not cause them to engage in action, as patches on jackets are something optional.

In the end, it is important that we make our work accessible to everyone. In our connected world, if the people don’t understand the problems that exist with security, things will get broken and the whole system might fail.

Kelley was Director of Communications at Tor in June, 2013, when an image of Snowden holding a laptop with a Tor sticker on it was released. Suddenly, the whole world was interested in what Tor is about and it was her job to explain it. She had to provide understanding about privacy and why not only bad people are using Tor. One way she explained Tor to journalists by using paperclips and envelopes to explain the protocol and let them try it out.

If we want to make the world a saver place, we need the public to engage in security. For this, we have to communicate problems to the public, but we need to make sure we do not scare them too much, as scared people will not engage. For this, there are a few things to consider: If we want to tell why something is important, we should not start with a scary story, but with something positive. Whenever we demonstrate a problem, we should also present a possible action, so that the public does not feel helpless. Finally, it might make sense to engage with a communications expert.

The full video of the talk can be found here.

From Zero to Secure Continuous Delivery in 60 Minutes by Florian Barth and Matthias Luft

Florian and Matthias presented a Marvel-themed talk on Continuous Delivery, that means, producing software in short cycles ensuring that it can be reliably released at any time, and the related security aspects, focusing on particularly relevant areas and common pitfalls.

Summary

Florian, acting as DareDeveloper in this talk, was dared by Captain Security to build a Continuous Delivery pipeline within thirty minutes. As a starting point, he explains the differences from an agile Continuous Delivery concept to the concept of static release cycles. The goal is to release software after every change on the source code, with the option to roll back to a working state and not to fear a big release that can break things or kill kittens. The concept of Infrastructure-as-Code take the Continuous Deployment to the next level. In IaC virtual hardware is defined in a file and created by a script. Appstack-as-Code is the concept to build a complete application stack, here in Docker containers, to get a service running.

The Continuous Deployment setup that was demonstrated, developed live, and actually finished within thirty minutes was:

Terraform for building infrastructure
Docker for running the application stack
GitLab for code hosting and…
Gitlab Runner for building and testing and…
Gitlab Container Registry for storing build artifacts
Amazon Web Services running Docker swarm

Matthias, acting as Captain Security in this talk, shows how to break out of Docker containers that use the Docker-in-Docker concept or mount the Docker socket as a volume. As any build environment is a remote-code-execution-as-a-service servie, this breakout possibility is a serious issue in multi-tenancy build system environments. Most developers consider building containers as safe, because the running code is contained, but breaking out to the build system isn’t impossible. From there the attacker can get the deployment credentials, log in to the running production servers and manipulate the service. The main threat is a developer which has access to the git repository and can commit code, which gets compiled automatically and than break out to steal the deployment credentials. The other possibility is that the attacker breaks out on the production servers.

Conclusions

Various other aspects of CI/CD pipeline security were briefly described, however, each aspect could have deserved another presentation. Thus the slides serve as a repository of security issues that must be addressed in a DevOps pipeline, for example having an enforcment point to scan images, deployment configurations and application stack configurations or traditional network isolation aspects as well.

Subverting Trust in Windows by Matt Graeber

Matt Graeber is a successful Security Researcher at SpecterOps Inc. He has done many reverse engineering and has done many talks in the past years, including conferences like Black Hat and Fal.Con.

What he brought to TROOPERS 18 for us was the topic of trust. Not only did he explain the technical details of trust in Windows, but also the general concepts and implications of trust in the industry.

His complete work, which you can find online from SpectreOps, since his talk was – as he said it – the hands on version of his research, focusing on live demos.

Summary

In the beginning, he talked a lot about trust in software in general. What is trust? Can you trust the Vendor? When can you trust software? (How) Can trust be abused?

He presented a “Trust Maturity Hierarchy” with the focus of software programming: The question was the reputation of code. As he said it, code signing is not an attestation of trust or intent. In reality, he said, signed basically means trusted. But can you really trust it based on if it is signed? Often there are no warnings about bad certificates or similar. Many valid and trustworthy code is not signed. So not signed doesn’t mean evil and signed doesn’t necessarily mean good. And bad certs are simply not enforced.

He then went into the details of Microsoft Windows trust and signature technics: To illustrate his points he showed different sigcheck examples for binaries and talked about how attackers can use code signing for their advantage. That attackers can sign their code even with valid and trusted certificates. Or they can just bypass code signing.

In his first attack live demo “Interface Package Hijacking”, he showed how to bypass code signing. He manually added a signature to a non-signed shady notepad.exe and then changed a registry key containing the path to the DLL that actually performs the certificate validation to a modified DLL.

After that, he did a so-called “Cert Cloning Attack”. An unprivileged user can clone the complete certificate chain used to sign valid software. He then re-uses all fields except the key fields to “look the same” as the original CA. The attacker can then install this “cloned CA” in the local user trust store without requiring administrative rights. See the details of this attack from SpectreOps Code Signing Certificate Cloning Attacks and Defenses.

He concluded with the question to the audience: Has your trust in code signature changed? And told the audience to keep these things in mind as a builder or defender.

Conclusions

Even signed code cannot be trusted
Signature verification is instable (no warnings for bad certs etc.)
Attackers can manually add signatures to their code
Attackers can copy valid trust chains and apply them to their code
There are few ways to detect malicious signatures in daily operation

Resources

Thanks for reading!

Rene Puder, Simon Janz, Ali Hardudi, Thomas Schlabach, Timo Harder, Malte Heinzelmann, Dennis Mantz, and Felix Rohrbach