Creating Splunk Alerts using API. As I mentioned in “Accelerating Splunk Dashboards with Base Searches and Saved Searches“, Splunk Reports are basically the Saved Searches. Moreover, Splunk Alerts are also the same Saved Searches with some additional parameters.
The question is what parameters you need to set to get the right Alert.
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.
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:
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?
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.
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.
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.
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:
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.
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.
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.
MIPT/PhysTech guest lecture: Vulnerabilities, Money and People. On December 1, I gave a lecture at the Moscow Institute of Physics and Technology (informally known as PhysTech). This is a very famous and prestigious university in Russia. In Soviet times, it trained personnel for Research Institutes and Experimental Design Bureaus, in particular for the Soviet nuclear program.
Nowadays MIPT closely cooperates with Russian and foreign companies, trains business people, software developers and great scientists. For example, the researchers who discovered Graphene and won Nobel Prize for this in 2010 were once MIPT graduates.
This is a very interesting place with a rich history. So it was a great honor for me to speak there.
New Advanced Dynamic Scan Policy Template in Nessus 8. According to Nessus 8.1.0 release notes, Tenable finally solved the problem with Mixed Plugin groups. At least partially. I will briefly describe the problem. Let’s say we found out that some Nessus plugins crash our target systems. This happens rarely, but it happens. So, we decided to disable these plugins in the scan policy:
Ok, problem is solved. But here is the question: what will happen with the new NASL plugins that will be added by Tenable in the same group, for example Misc.?
The answer is quite sad: Nessus doesn’t know if they should enabled of disabled, so they will be disabled in the scan policy by default. And this can lead to some False-Negatives. For example, on this screenshot you can see a fresh plugin “Xen Project Guest p2m Page Removal Error Handling DoS (XSA-277)” Published: December 13, 2018 was automatically disabled.
Previously, it was necessary to monitor this situation and add these plugins to Enabled manually or via API. But now with a new Dynamic Scan Policy template, this might be changed.
Guinea Pig and Vulnerability Management products. IMHO, security vendors use the term “Vulnerability Management” extremely inaccurate. Like a guinea pig, which is not a pig and is not related to Guinea, the current Vulnerability Management products are not about the actual (practically exploitable) vulnerabilities and not really about the management.
Vulnerability should mean something solid and reliable, something that can be practically used by a malicious attacker or penetration tester.
When (so-called) Vulnerability Management vendors start working with indirect information from third-party about potential vulnerabilities in the software, that were possibly exploited by someone in some unknown conditions, or simply distance from responsibility: “we just provide information from the software vendor; software vendor knows better about the vulnerabilities in his own products”, it’s all falling into to the area of fortune telling and counting angels on the head of a pin.
Hardcore process of identifying weaknesses that real-life attackers can use moves to a boring compliance. For example, as PCI DSS requires, there should be no vulnerabilities above medium level (CVSS Base score > 4). At the same time, no one cares how fair this assessment of criticality is or how real these vulnerabilities are. All the analytics build on such formal data loses its sharpness and practical value.
This is my personal blog. The opinions expressed here are my own and not of my employer. All product names, logos, and brands are property of their respective owners. All company, product and service names used here for identification purposes only. Use of these names, logos, and brands does not imply endorsement. You can freely use materials of this site, but it would be nice if you place a link on https://avleonov.com and send message about it at me@avleonov.com or contact me any other way.