Vulners Linux Audit API for Host Vulnerability Detection: Manual Auditing, Python Scripting and Licensing. Hello everyone! This episode will be about Vulners Linux Audit API, which allows you to detect vulnerabilities on a Linux host knowing only the OS version and installed packages. I had a similar post about this 4 years ago, but some details have changed, so I came back to this topic.
Tag Archives: Ubuntu
No left boundary for Vulnerability Detection
No left boundary for Vulnerability Detection. It’s another common problem in nearly all Vulnerability Management products. In the post “What’s wrong with patch-based Vulnerability Management checks?” I wrote about the issues in plugin descriptions, now let’s see what can go wrong with the detection logic.
The problem is that Vulnerability Management vendors, in many cases, have no idea which versions of the Software were actually vulnerable.
OMG?! How this can be true? 🙂 Let’s take an example.
Each vulnerability at some points in time:
- was implemented in the program code as a result of some mistake (intentional or not)
- existed in some versions of the program
- was detected and fixed
Read more about this in “Vulnerability Life Cycle and Vulnerability Disclosures“.
Let’s suppose that we have some Software A with released versions 1, 2 … 20.
Just before the release of version 10, some programmer made a mistake (bug) in the code and since the version 10 Software A has become critically vulnerable. Before the release of version 20, Software Vendor was informed about this vulnerability and some programmer fixed it in version 20. Then Software Vendor released a security bulletin: “Critical vulnerabilities in the Software A. You are not vulnerable if you have installed the latest version 20.”
And what does Vulnerability Management vendor? This vendor only sees this security bulletin. It is logical for him to decide that all versions of Software A starting from 1 are vulnerable. So, it will mark installed versions 1 … 9 of the Software A as vulnerable, even so actually they are NOT.
Packabit project: building Nmap deb packages for Ubuntu
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.
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.
Making Vulnerable Web-Applications: XXS, RCE, SQL Injection and Stored XSS ( + Buffer Overflow)
Making Vulnerable Web-Applications: XXS, RCE, SQL Injection and Stored XSS ( + Buffer Overflow). In this post I will write some simple vulnerable web applications in python3 and will show how to attack them. This is all for educational purposes and for complete beginners. So please don’t be too hard on me. 😉
As a first step I will create a basic web-application using twisted python web server (you can learn more about it in “Making simple Nmap SPA web GUI with Apache, AngularJS and Python Twisted“).
Deploying VirtualBox virtual machines with Vagrant
Deploying VirtualBox virtual machines with Vagrant. I often use virtual machines for various tasks: from building software packages to testing software products or PoCs for vulnerabilities. Creating a virtual machine in Oracle VirtualBox is a time-consuming and annoying process: set parameters of VM, attach iso, make dozens of clicks in OS installation GUI interface, wait until everything is installed, configure network and install guest additions.
Of course you can create an image of the base machine once and clone it each time you need it. But from time to time you will still need to recreate this image, for example for a new Linux release. It would be much easier, if we could get a fresh and clean Virtual Machine that meets our requirements and with minimal effort. And this is what Vagrant by HashiCorp does.
Vulnerability Databases: Classification and Registry
Vulnerability Databases: Classification and Registry. What publicly available Vulnerability Databases do we have? Well, I can only say that there are a lot of them and they are pretty different. Here I make an attempt to classify them.
It’s quite an ungrateful task. No matter how hard you try, the final result will be rather inaccurate and incomplete. I am sure someone will be complaining. But this is how I see it. 😉 If you want to add or change something feel free to make a comment bellow or email me@avleonov.com.
The main classifier, which I came up with:
- There are individual vulnerability databases in which one identifier means one vulnerability. They try to cover all existing vulnerabilities.
- And others are security bulletins. They cover vulnerabilities in a particular product or products. And they usually based on on patches. One patch may cover multiple vulnerabilities.
I made this diagram with some Vulnerability Databases. Note that I wanted to stay focused, so there are no exploit DBs, CERTs, lists of vulnerabilities detected by some researchers (CISCO Talos, PT Research, etc.), Media and Bug Bounty sites.
For these databases the descriptions of vulnerabilities are publicly available on the site (in html interface or downloadable data feed), or exist in a form of paid Vulnerability Intelligence service (for example, Flexera).
On one side there are databases of individual vulnerabilities, the most important is National Vulnerability Database. There are also Chinese, Japanese bases that can be derived from NVD or not.
On the other side we have security bulletins, for example RedHat Security Advisories.
And in the middle we have a Vulnerability Databases, for which it is not critical whether they have duplicated vulnerability IDs or not.
Vulchain scan workflow and search queries
Vulchain scan workflow and search queries. This post will be about my Vulnerability Scanner project – Vulchain. Recently I’ve spent couple of my weekends almost exclusively on coding: refactoring the scan engine, creating API and GUI.
I was doing it because of the conferences, where I will be speaking soon:
- April 11-13 CyberCentral in Prague. upd. Read about it at “CyberCentral Summit 2018 in Prague“
- April 23–24 CISO Forum. upd. Read about it at “CISO Forum and the problems of Vulnerability Databases”
- May 15–16 PHDays in Moscow. upd. Read about it at “PHDays8: Digital Bet and thousands tons of verbal ore“
Pretty intense schedule for a guy who spends most of his time in PyCharm and Linux console. 😉 Very excited! So, it seemed right to add a couple of slides about my project and show that something is already working.