Category Archives: Vulchain

Microsoft Patch Tuesday June 2022: Follina RCE, NFSV4.1 RCE, LDAP RCEs and bad patches

Hello everyone! This will be an episode about the Microsoft vulnerabilities that were released on June Patch Tuesday and also between May and June Patch Tuesdays.

Alternative video link (for Russia): https://vk.com/video-149273431_456239094

On June Patch Tuesday, June 14, 56 vulnerabilities were released. Between May and June Patch Tuesdays, 38 vulnerabilities were released. This gives us 94 vulnerabilities in the report.

Continue reading

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.

Vulchain scan workflow and search queries

I was doing it because of the conferences, where I will be speaking soon:

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.

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