This blogpost contains summaries of talks from this year’s TROOPERS19 Attack & Research Track.
VXLAN Security or Injection, and protection
The talk “VXLAN Security or Injection, and protection” was held by Henrik Lund Kramshøj, who is the owner of Zencurity ApS, a small security company located in Denmark.
Henrik gives an overview about lesser known VXLAN insecurities, mostly packet spoofing.
In the end he gives advice how to protect against this attacks.
Summary
Henrik first describes why it is important to take a look at the security of Virtual Extensible LAN (VXLAN), a network virtualization technology used to encapsulate OSI layer 2 Ethernet frames within layer 2 UDP datagrams. But it has some problems, one being that Vendors hype the speed of their VXLAN implementations, but don’t look at security issues, another that lots of VXLAN setup guides don’t show how to configure it to be secure. He also warns, that too many of today’s network analyzing tools don’t take a look in VXLAN packets and so don’t find attacks hidden within them.
Then Henrik gives an overview over how VXLAN works on a small example and afterwards asks how to secure it, since VXLAN doesn’t provide any security by itself. Some vendor got some documentations about VXLAN security, like Arista.
But for example Cisco’s VXLAN EVPN Multi-Site Design and Deployment manual with 55 pages doesn’t contain the word security a single time. He concludes that security is not detailed enough in the “how to setup VXLAN”.
With the network put together he started so show how some spoofing attacks could look like.
Using Scapy he did build spoofed packets containing IP+UDP packets and send those from the Internet to the VXLAN Router. The VXLAN packets were accepted, since there weren’t any checks in place nor was authentication needed, and successfully unpacked. The wrapped IP+UDP packets were then send into the internal network. With a method to get packets into a network he gives examples of packets one could inject. Sending for example an UDP DNS request to an internal DNS server it is possible to get the response back through the firewall with the additional result of an UDP hole in most firewalls. It’s quite bad to get packets from the internet that easy into the internal network and even responses back.
Next he discussed how to get some required parameters for VXLAN packets. The vxlanport being 4789 (RFC 7384) or the Linux kernel default 8472, he speculated that vni=destination VLAN, which can have 4096 values, for destination mac the broadcast mac could be used and for the destination ip to try the internal network ip’s.
In the end he wished for better testing tools for scanning and attacking. He warned that many firewalls/IDS/DDoS protection systems don’t see VXLAN traffic, but that he did add VXLAN to a Hping3 fork, Zeek and Suricata
He concluded that if one uses VXLAN they should think about security and that it might be good to not even use VXLAN.
Conclusion
Henrik showed us how easy it is to spoof VXLAN packets and how to leverage this vulnerability. He gave some ideas about how to choose needed values for VXLAN packets and in the end give some advises on how to secure VXLAN: Let the firewall that can handle VXLAN packet handle them too.
Fetch Exploit – attacks against source code downloaders by Etienne Stalmans
What can happen if you only download source code? At his Troopers19 talk Fetch Exploit – attacks against source code downloaders Etienne Stalmans demonstrated how attacks, especially focused on the source code downloading process, can affect the whole software supply-chain and DevOps pipeline. He also pointed out some possibilities to secure these pipelines.
Etienne Stalmans himself is part of the Heroku security team as a Technical Lead. He works on herding containers and is looking after container services and whether they are running in a secure way.
At the beginning of his talk, Etienne Stalmans touched upon the quite complex Git protocol, which is becoming increasingly popular. But as the main problem, he mentioned that no one checks what happens after the code was checked in the repository and turned into infrastructure without some research. When source code is downloaded the attack occurs before the build script was triggered and if a vulnerability exists in Git, all of Git’s tools are affected by it.
The first examined vulnerability in this talk relating to the Git protocol was the CVE-2018-11235 which leads to code execution. The vulnerability occurs when Git clones a checked-in repository and uses the content from a malicious submodule, which should actually depict the dependencies between different repositories, thinking it might contain the Git information. But we only get code-execution with the git post-checkout hook which is executed from the malicious submodule configuration after cloning. Since only this script is abused there is no need for further injections or memory corruptions.
He also mentioned that malicious submodules can be hidden in various nested, recursively cloned submodules. The point of this attack is that users and their analyzers won’t spot this because it is not in the source code – only in the directory structure. Therefore, Etienne Stalmans showed a demo exploiting this issue from the user’s and the attacker’s perspective on the example of docker build in his slides and the code-execution happened before the container is actually created.
Furthermore, there are other ways to trick Git into doing things we want or abuse the way other tools are using Git. Secondly, he presented CVE-2018-16873 containing a vulnerability in go get which allows remote code execution.
But why does this work? With the import of a malicious Go package, it is possible to rearrange the directory structure so that after cloning the Git repository, the parent directory is considered as the repository root that executes Git commands. This is achieved with the go-import meta tag and nested imports. Unlike the previous vulnerability, nothing triggers the Git hooks for code execution. As a way around a Git config file containing malicious commands in the Proxy configuration could change the protocol and could be executed on the system as soon as running a go get -u.
Summarizing, the speaker Etienne Stalmans showed how to put this together and get a nice clean exploit and run arbitrary code in the context of the victim. And he revealed that another vulnerability is still in docker itself. Another patch will come soon! Keep in mind and check (it) out on his Blog. 🙂
What can we do to prevent these attacks? Etienne Stalmans recommended to carry out a good supply-chain management with e.g. checking whether modules have the right signature, use new secure versions of libraries downloading your source code and fetch the source code in an isolated system. If you are interested in learning more about these vulnerabilities in the source code downloading process and their demonstrations, you should definitely take a look at the video of the talk.
Thanks for reading!
Nils Emmerich, Pascal Turbing, Linda Huischen, Tillmann Osswald