This post is Part 2 of the “Offensive Infrastructure with Modern Technologies” series, and is going to focus on an automated deployment of the HashiCorp stack (i.e., the HashiStack).
Part 1 explained how to
configure Consul in both single and multi node deployments using docker-compose,
while here I’m going to provide a step-by-step walkthrough that will allow you to automatically deploy the full stack with Ansible.
On the 3rd of December 2018, a critical security vulnerability affecting Kubernetes API server has been announced. Without any surprise, this announcement got a lot of traction (especially on Twitter).
More info on CVE-2018-1002105. Recently disclosed Kubernetes vulnerability allows all users, authenticated and unauthenticated, backdoor administrative access to the API server, including the kubelet...and it can't easily be detected in logs. https://t.co/UfdCrajequ
— Ian Coldwater 👻🌿 (@IanColdwater) December 3, 2018
In this post I’ll try to dissect the information currently available.
In the past few weeks I’ve been reading “The Hacker Playbook 3: Red Team Edition” from Peter Kim. As the title clearly states, this version focuses on processes and techniques that can be used during a red teaming engagement. Although I’m not going to provide a review of the book here, I highly recommend it to anyone interested in the field.
While going through the book I found myself building a mindmap to link topics (which not always are presented sequentially) together, so to create a high-level methodology as suggested by Peter. In this post I want to share this mind map: I do realise this is not a complete list of all techniques/tools that can be leveraged in a campaign, but it covers what’s in “The Hacker Playbook 3”. I hope you’ll find it useful!
A while ago I posted “So I Heard You Want to Learn Kubernetes”, where I tried to demystify the perception by which Kubernetes is believed to be too hard to even get started, by walking through the journey I undertook to get the basics first, and to focus on its security aspects later.
The natural evolution was to put into practice those concepts, but I quickly realized there was a shortage of resources that gave a comprehensive overview of (offensive) security tooling for that space. As with many topics in this industry, information is often scattered and non-uniform.
@ToniBlyx, in his post “My arsenal of AWS security tools”, gave it a go. That post was indeed the starting point for this one, but I felt the need to personalize that list and to add tools not only for AWS, but also for Docker, Kubernetes, and even Git.
In this post I’ll focus on providing a curated list of tools I personally find useful, alongside a quick “usage” guide for each one of them. I’ve also released an Ansible role for those who want to quickly deploy them.
On the 16th of October 2018, an important security release from libssh
has been published in order to address CVE-2018-10933:
libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials.
The bug was discovered by Peter Winter-Smith of NCC Group.
Since then, many people started debating on Twitter about causes and impact. So here I want to writeup a practical guide which explains how to find hosts (in your network) vulnerable to the libSSH Authentication Bypass, and how to exploit them to gain shell access.
