Monthly Archives: January 2019

What’s wrong with patch-based Vulnerability Management checks?

My last post about Guinea Pigs and Vulnerability Management products may seem unconvincing without some examples. So, let’s review one. It’s a common problem that exists among nearly all VM vendors, I will demonstrate it on Tenable Nessus.

If you perform vulnerability scans, you most likely seen these pretty huge checks in your scan results like “KB4462917: Winsdows 10 Version 1607 and Windows Server 2016 October 2018 Security Update“. This particular Nessus plugin detects 23 CVEs at once.

What's wrong with patch-centric Vulnerability Management?

And, as you can see, it has formalized “Risk Information” data in the right column. There is only one CVSS score and vector, one CPE, one exploitability flag, one criticality level. Probably because of architectural limitations of the scanner. So, two very simple questions:

  • for which CVE (of these 23) is this formalized Risk Information block?
  • for which CVE (of these 23) exploit is available?

Ok, maybe they show CVSS for the most critical (by their logic) CVE. Maybe they somehow combine this parameter from data for different CVEs. But in most cases this will be inaccurate. Risk information data for every of these 23 vulnerabilities should be presented independently.

As you can see on the screenshot, one of these vulnerabilities is RCE the other is Information Disclosure. Vulnerability Management solution tells us that there is an exploit. Is this exploit for RCE or DoS? You should agree, that it can be crucial for vulnerability prioritization. And more than this, in the example there are 7 different RCEs in Internet Explorer, MSXML parser, Windows Hyper-V, etc. All this mean different attack scenarios. How is it possible to show it Vulnerability Scanner like one entity with one CVSS and exploitability flag? What can the user get from this? How to search in all this?

Continue reading

Managing JIRA Scrum Sprints using API

Atlassian Jira is a great tool for organizing Agile processes, especially Scrum. But managing Scrum Sprints manually using Jira web GUI maybe time consuming and annoying. So, I decided to automate some routine operations using JIRA API and Python.

The API calls are described on the official page at JIRA Agile REST API Reference.

Managing JIRA Agile Sprints using API

I will use my domain account for authentication. First of all let’s see how to get Jira Scrum Board ID by it’s name and get all the Sprints related to the Board.

Continue reading

Packabit project: building Nmap deb packages for Ubuntu

During the long New Year holidays (30 dec – 8 jan) I started a new project: Vagrant-based Linux package builder called Packabit. I thought it might be nice to have scripts that will automatically build a Linux packages from sources and will NOT litter main system with unnecessary packages. Something like a very simplified build server.

Packabit - Vagrant-based Linux package builder

Why might someone want to build Linux packages on their own?

Official repositories of Linux distros usually contain pretty old versions of packages. Let’s take, for example, Nmap. The only version of Nmap available in the repository for Ubuntu 18.04.1 LTS is 7.60 , and the latest stable version of Nmap available on official website is 7.70.

Release dates according Nmap changelog:

  • Nmap 7.70 [2018-03-20]
  • Nmap 7.60 [2017-07-31]

The latency is more than a year.

Is it really necessary to use the latest version? Actually, yes. Every new version of Nmap contain more banner detects and service detects and produce more adequate results. Nmap project offers official packages only for RPM-based distributions: CentOS, RHEL, Fedora, etc. And if you need packages for DEB-based distributions, Debian, Ubuntu, Kali, etc. you should build them yourself.

What is the Packabit?

Currently it’s just 2 bash scripts for building stable Nmap package for Ubuntu 18.04: one is for creation and launching Vagrant virtual machine, the other runs on guest virtual machine and build Nmap package from the sources.

How to try it

I want this project to be as opensource as possible. If anyone wants to give it a try, get it from Github. For the end-user it looks like this: run the script build_nmap.sh, wait for 10 minutes and get new package from the packages directory. There won’t be any litter in a process. Each time a new virtual machine for building will be automatically created and then destroyed.

Continue reading