Monthly Archives: January 2018

Vulners Web Vulnerability Scanner plugin for Google Chrome v. 2.0

Vulners Team released today the second version of their Web Vulnerability Scanning plugin for Google Chrome browser. You can read my description of the version 1.0 at “ vulnerability detection plugins for Burp Suite and Google Chrome“.

Vulners web vulnerability scanner v.2.0

Killing feature of Vulners web scanner v. 2.0 is that you can now see all vulnerabilities on all scanned sites in a single window. You don’t need to checks all Google Chrome tabs manually.

Moreover, if some sites make request to other servers, for example, these servers will be checked automatically.

The plugin was fully refactored and now it is React driven. It works faster, analysis more data sources and detects vulnerabilities more accurately.

Continue reading

Kenna Security: Analyzing Vulnerability Scan data

I’ve been following Kenna Security (before 2015 Risk I/O) for a pretty long time. Mainly, because they do the things I do on a daily basis: analyse various vulnerability scan results and feeds, and prioritize detected vulnerabilities for further mitigation. The only difference is that my scripts and reports are highly specific for my employer’s infrastructure and needs. And guys from Kenna team make a standardized scalable cloud solution that should be suitable for everyone.

I think their niche is really great. They do not compete directly with Vulnerability Management vendors. They can be partners with any of them, bringing additional features to the customers. Perfect win-win combination. That’s why Kenna speakers regularly participate in joint webinars with VM vendors.

I couldn’t lose a great opportunity to see Kenna Security service in action. 😉

In this post I will try to make a very brief review of Kenna functionality and formulate pros and cons of the solution.

When you submit trial request at (or if you are not in Europe) you will get a link to your company account:

The login screen will look like this:

Kenna login

Continue reading

Confluence REST API for reading and updating wiki pages

In previous posts I wrote how to automate the work with Atlassian Jira, including automated ticket labeling. Now let’s try to use REST API of another popular Atlassian product – Confluence wiki engine.

Confluence REST API

What you may want to automate in Confluence? Obviously, it may be useful to read the pages that your colleagues regularly update and then use this data in some scripts as an input. You may also want to update your own Confluence pages, for example to post Vulnerability Scanning results. 😉

Continue reading

Tracking changes in CERT bulletins and Nessus plugins using Vulners Time Machine

If you use vulnerability search engine, you probably know that it has a real “Time Machine”.

Vulners Time Machine cases

Each time Vulners sees some changes on a source page it creates a new version of security object. And you can see the full history of changes in a nice GUI:

Vulners Time Machine

In most cases, the vendor just corrects typos or adds more details. But sometimes the message can change significantly. Meltdown and Spectre

For example, in a case of latest Meltdown and Spectre vulnerability. Initial VU:584653 recommendation was “Replace CPU hardware”. 🙂

Continue reading

Vulchain Scanner: 5 basic principles

New Year holidays in Russia lasts 10 days this year! Isn’t it an excellent opportunity to start a new project? So, I decided to make my own active network vulnerability scanner – Vulchain.

Why? Well, first of all, it’s fun. You can make the architecture from scratch, see the difficulties invisible from the user side and try something new in software development as well.

Vulchain modular scanner

Basic principles of the project. This is not a dogma, but rather a general direction.

  1. Data layers. I would like to have this independent sets of data:
    • Raw data collections
    • Software versions detected from the raw data
    • Vulnerabilities detected from the software versions
    • Exploitability assessment data for the detected vulnerabilities
  2. Modularity. Most of functionality will be performed by the independent modules which read some data from one data level, and create some data on other data level.
  3. Transparency. Data is stored constantly on the all levels. You can easily figure out how the data was  processed, track the errors and modify modules.
  4. Neutrality. All modules are independent and easily replaceable. For example:
  5. Rationality. If it is possible to use some security utility, service or product, we will integrate with them, rather than writing our own analogue. We spend resources only on what will give us the maximum profit at a minimum of costs. 😉

Continue reading