Vulnerability Management at Tinkoff Fintech School

In the last three weeks, I participated in Tinkoff Fintech School – educational program for university students. Together with my colleagues, we prepared a three-month practical Information Security course: 1 lecture per week with tests and home tasks.

Each lecture is given by a member of our security team, specialized in one of the following modules: Vulnerability Management, Application Security, Infrastructure Security, Network Security, Virtualization Security, Banking Systems Security, Blue & Red-teaming, etc.

Vulnerability Management at Tinkoff Fintech School

The course is still ongoing, but my Vulnerability Management module is over. Therefore, I want to share my impressions and some statistics.

Lecture

The content was pretty much the same as for my lecture at MIPT in December last year. I removed some boring slides about Vulnerability Databases, added some more critics of Vulnerability Management products, their reports and detection methods. And I also updated information about open vacancies related to Vulnerability Management.

Testing

In the beginning of each lecture, students should solve some tests based on the materials of the previous lecture. Basically it is for motivating them to visit lectures. 😉

I always wondered why Information Security tests are always so weird. They either check the knowledge of some terms or definitions invented by some nonames or the knowledge of reference data, the markings of fire extinguishers in the CISSP exam, for example. Or it is a fascinating game: guess the logic of the individual, who made this question. Anyway, it’s far from the real life and the real practice.

Well, I thought so until I had to make my own questions. 🙂 It turned out that it’s pretty hard to make them unambiguous, reasonable and not based on the subjective experience. As a result, the questions were about Vulnerability Management process, Vulnerability life cycle, basic vulnerability types, and Vulnerability Detection issues. All this were in the lecture. Many students answered all the questions correctly, so it seems to me that the test wasn’t bad.

Homework

And the most interesting and intriguing part was the homework. There were 2 tasks and the deadline was two weeks.

Task 1. Vulnerability Detection and Exploitation

Deploy virtual machines in your home environment:

  1. Vulnerable Target host (for example, Metasploitable or an old version of Windows/Linux)
  2. Vulnerability Scanner (for example, Nessus Home, OpenVAS, Nexpose Community)
  3. Exploitation Tool (for example, Metasploit or some separate exploits)

Run vulnerable service on a Vulnerable Target host (for example, SSH), detect vulnerability with Vulnerability Scanner, exploit a vulnerability and get remote access to the host. Make a report how you did it step by step and describe each of your choices.

Bonus: write your own detection script for the exploited vulnerability.

In this task I wanted the students to see

  • how the vulnerability could be detected and exploited;
  • that the Vulnerability Scanner is not some magical tool and they can make a small scanner on their own.

The task was intentionally formulated in a very wide way, without mentioning actual tools and vulnerabilities, because I was curious what exactly would they choose. So, those who are not really interested in the topic could choose something easy, and those who like this stuff could use this task to make an interesting research.

Most of the students chose Metasploitable as a vulnerable target host. Actually, this is the easiest way. But, as you can see, some students chose the usual operating systems: Windows, Ubuntu Linux and docker containers.

Vulnerable Target Hosts

The same number of students used Nessus Home and OpenVAS for vulnerability detection. They registered Nessus Home on their own and used it at home environment, so the license agreement was not violated.

Vulnerability Scanners

In most cases students used Metasploit for exploitation. But sometimes it were some custom python scripts or just a curl.

Exploitation Tools

They exploited very different vulnerabilities:

Exploited Vulnerabilities
  1. BID:48539 – vsftpd Compromised Source Packages Backdoor Vulnerability
  2. CVE-2004-2687 – DistCC Daemon Command Execution
  3. CVE-2007-2447 – Samba “username map script” Command Execution
  4. CVE-2008-0166 – Predictable PRNG Brute Force SSH
  5. CVE-2010-2075 – UnrealIRCD 3.2.8.1 Backdoor Command Execution
  6. CVE-2015-1427 – Elasticsearch Search Groovy Sandbox Bypass
  7. CVE-2017-12617 – Apache Tomcat JSP Upload Bypass / Remote Code Execution
  8. CVE-2017-9462 – Mercurial Custom hg-ssh Wrapper Remote Code Exec
  9. CVE-2019-0724 – Microsoft Exchange Server Remote Privilege Escalation Vulnerability
  10. Distributed Ruby – Distributed Ruby Remote Code Execution
  11. MS08-067 – Vulnerability in Server Service Could Allow Remote Code Execution
  12. MS17-010 – Remote code execution in Microsoft Server Message Block 1.0 (SMBv1) server (EternalBlue)
  13. ssh bruteforce – brute-force guess SSH login credentials

I liked the most exploitation of Apache Tomcat RCE (in a docker image), classical MS17-010 and new Microsoft Exchange Server issue, because these are the most practical cases. The bruteforce of SSH logins and passwords was not the exploitation that was expected in this task, but why not, this also often happens. 🙂

And finally the detection scripts. Most of them were unauthenticated and version-based, written in python or bash.

Custom Detection Scripts

Task 2. Vulnerability Scoring

Find a new CVE vulnerability without a CVSS vector on nvd.nist.gov (“UNDERGOING ANALYSIS” state) and make CVSS v.3 Base and Temporal Vector for it. Justify your choice. It is advisable to pass the task before the vector will be published on the NVD website.

In this task I wanted students to see how the criticality of a vulnerability (that Vulnerability Scanner shows) is actually being produced. The vector was not really matter. In fact, it was possible to get Base Vector from the original vulnerability research. 😉 The important part was the justification like “I chose Attack Vector (AV): Network because…” just to be seen that this is not a random choice. 🙂

As you can see, very few people take the same vulnerabilities, that is definitely a good sign:

CVSS vectors

It also might be interesting to compare the vector that they’ve got as a result of this task with the vector from the NVD. Most likely there will the differences because CVSS is pretty subjective.

In conclusion

This was my second time when I gave a lecture and the first time I made additional educational content: tests and homework. It was very cool and exciting. I hope the students have their fun too.

This was only the first module, there is still a lot of content and interesting practical tasks from my colleagues. I hope that all the students will successfully go through all the stages and with some of them we will meet at work or on internship.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.