| Follow @lancinimarco

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.

Kubernetes is getting popular by the day, and is probably one of the hottest buzzwords of 2018.

With names like eBay, Goldman Sachs, Huawei, ING, SAP, and many others listed as corporate users, it is surely a technology which has got a consolidated place in our industry.

At the same time, Kubernetes got the infamous nomea of being hard to understand. Mostly due to rumors, but some other times it has been proven to be easy to get wrong, like experienced by the Monzo team a few months back:

I still remember the sense of confusion when I decided I wanted to get a better understanding of Kubernetes, as I felt like I didn’t know where to start, or what to tackle first.

This post is part of the “Kubernetes Primer for Security Professionals” series, and is going to try 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 later to focus on the security aspects.

Hopefully this will help a little in your own journey to understand Kubernetes.

A couple of months ago I released GoScan, which started more as a side-project useful for me to learn @golang.

The original idea was to port in Go a collection of python scripts I created years ago while taking OSCP, and then rarely used afterwards due to their “hacky” nature (hey, in OSCP time is everything, and you don’t really care about being stealthy, or “polite” against your targets).

I now wanted something more stable that I could use even during professional pentests, so I spent some time refactoring and refining the codebase.

Have you ever been in a network penetration test where the scope is so huge you end up with dozens of files containing Nmap scan results, each of which, in turn, contains a multitude of hosts? If the answer is yes, you might be interested in this blog post.

Following is the process I recently went through to find a way to triage the results, while enabling concurrent collaboration between team mates. We will see how using traditional “defensive” tools for Offensive security data analysis has advantages over the traditional grep when parsing and analysing data.

Finally, I’m going to provide the full source code of the setup I ended up with. Hopefully this will give someone else with a similar need some help in the future.