How would I hack Runet?

In today's article we will share the results of more than a year-long project CyberOKdedicated to the analysis of the security of the Runet perimeter.

The study contains detailed statistics on some cases, analytical conclusions, as well as major incidents and dangerous vulnerabilities identified during the work. Particular attention is paid not only to technical, but also to organizational aspects of the response to identified vulnerabilities. In addition, the article describes the technical nuances that we encounter when implementing such large-scale projects, as well as the use of buzzwords such as LLM, CNN and others to automate routines and increase work efficiency.

The report “How would I hack the Runet” was presented for the first time at an international scientific and practical conference RusCrypto 2024 Igor Pervushin – head of the direction of creating a knowledge base at CyberOK.

Introduction

In order to hack something, you must first find out: what is it?

Let's start with the scale of the number of resources that we need to check. We at CyberOK collected the following statistics using the attack surface monitoring and reporting system (SKIPA), which we have developed and are improving, as well as data from other Attack Surface Management class systems:

  • 47.5M IP addresses – Runet address space.

  • 7.2M of them are “live”. This assumes that the IP address has at least one network port.

  • At the same time, all IP addresses host 71.7M services from which information can be obtained, which, in particular, can be used by attackers. These statistics also include services that were obtained during the analysis of domain names.

  • 63.5M are services that operate over the HTTP protocol, but in addition to it, more than 125 different protocols are used.

  • In total, we discovered more than 3,000 different types of software. If we take into account that each of the services hosts more than 1 type of software, then the numbers with possible attack points for vulnerabilities increase exponentially.

For an attacker, a larger attack surface is an advantage because the more opportunities there are, the more likely it is that the attack will be successful.

Next, we are faced with the following question: how to sift through all this diversity in order to spend the least amount of resources and at the same time bring as much “benefit” as possible? How to cut off everything unnecessary to get to something precious?

Optimizing scanning and automating the search for vulnerabilities: CyberOK methods

Already at the stage of port scanning using our technology SKIPA we are faced with the fact that “not all ASMs are equally useful.” Thus, according to data as of 03/20/24, port 10050 is practically absent in Shodan and Censys, while we found about 135 thousand nodes. The Zabbix agent is most often located on this port.

Fig. 1 Statistics on the occurrence of port 10050 in Runet in Censys

Fig. 1 Statistics on the occurrence of port 10050 in Runet in Censys

Fig.2 Statistics on the occurrence of port 10050 in Runet in Shodan

Fig.2 Statistics on the occurrence of port 10050 in Runet in Shodan

Fig.3 Statistics on the occurrence of port 10050 in Runet in SKIPA

Fig.3 Statistics on the occurrence of port 10050 in RuNet in SKIPA

In a situation where the numbers are only growing, it is necessary to resort to magic, which both optimizes the scanning process and allows us to do most of the work for us. I'll tell you about two of the many methods we use.

Method 1: Optimize TCP Port Scanning

Checking all TCP ports on the RuNet is quite an expensive procedure, both in terms of resources and time. Is it possible to somehow optimize the process so as not to knock on every door? At the moment, we are improving our algorithm for scanning IP addresses based on predicting the network ports that are found in the segment under consideration, which allows us to scan not all 47.5KK IP addresses for all 65K ports, but only some part of them. And this hypothesis is confirmed. Let's look at the pictures:

Fig.4 Comparison of the curves of the predictive method (yellow) and exhaustive search of ports (blue), which are divided by ASNs

Fig.4 Comparison of the curves of the predictive method (yellow) and exhaustive search of ports (blue), which are divided by ASNs

Here we see graphs of the dependence of the number of scanned ports and the approach to the standard. The upper curve is responsible for statistics summed up for a group of nodes, the lower one for all found IP addresses. You can see how much faster the top curve rises. This fact suggests that for some segments (in this case ASNs) it is possible to build a profile of the most important ports for scanning, which will cover most of the services.

In order to get statistics, ideally it is necessary to conduct a full port scan on 65535 ports, which is also an expensive pleasure for the entire segment.

Fig.5 Comparison of scanning graphs for all IP addresses of a segment (blue) and 10% of IP addresses in a segment (yellow)

Fig.5 Comparison of scanning graphs for all IP addresses of a segment (blue) and 10% of IP addresses in a segment (yellow)

Figure 5 shows the coverage of network ports and services when taking 10% of the segment's IP addresses. You can see how much they coincide, which confirms the hypothesis that it is possible to build a profile based on some part of the data.

Method 2: Automate Software Definition

If with network scanning everything is simpler – it’s just machine resources, then with writing rules for defining software it’s more complicated – our experts are working on this. One of the phases is passive detection, in which we use regular expressions. In this case, the process contains 2 approaches. The first is the use of rules written by experts, the second is rules obtained in an automated manner. Automation uses a large language model that is trained on service responses, as shown in Figures 6-7-8. As a result, we get some regularity with less accuracy in determining the software, but at the same time we save a lot resources.
For example, I have never heard of Ratchetand you?

Fig.6 Example of the resulting regular expression

Fig.6 Example of the resulting regular expression

Fig.7 Examples of specific software

Fig.7 Examples of specific software

Fig. 8 An example of resource clustering, on the basis of which a regular expression is formed

Fig. 8 An example of resource clustering, on the basis of which a regular expression is formed

When all the data has finally been collected and the difficulties have been overcome, we begin the hunt.

Features of the national hunt: Tactics and attack techniques

We have identified 5 tactics and techniques that can be used by attackers when planning attacks taking into account regional characteristics, because not everything is so simple:

  1. Monitoring trending vulnerabilities

  2. Region-specific software

  3. Often vulnerable technologies

  4. Ports with specific software

  5. What they're trying to hide

Let's look at each of them with examples.

1. Monitoring trending vulnerabilities

The first tactic that we can use is monitoring trending vulnerabilities. From the latest:

  • TeamCity (CVE-2024-27198)

  • ConnectWise (CVE-2024-1709)

  • Fortinet (CVE-2024-21762)

  • WordPress (…)

  • Gitlab (CVE-2023-7028)

It is important to note that in addition to standard metrics, such as CVSS, it is important to consider the prevalence of the software. So, for example, the vulnerability in ConnectWise, although it spread massively in the information field, had virtually no impact on the Russian segment of the Internet.

As a result, this tactic can be represented by the “waiting” mode, in which the addition of new checks in known software occurs quite quickly and sometimes does not require rescanning, which means an almost instant result.

Fig.9 Zhdun, together with the townspeople, awaits the arrival of broadband Internet in Norilsk.  And we are waiting for cool waves.

Fig.9 Zhdun, together with the townspeople, awaits the arrival of broadband Internet in Norilsk. And we are waiting for cool waves.

Below are statistics showing that different vulnerabilities have different impacts on both the amount of resources and the potential number of organizations affected. We can conclude that the release of a new critical vulnerability in GitLab could be fatal. We’ll talk about how this kind of system is corrected a little later.

Fig.10 TeamCity (CVE-2024-27198)

Fig.10 TeamCity (CVE-2024-27198)

Fig. 11 GitLab (CVE-2023-5009)

Fig. 11 GitLab (CVE-2023-5009)

2. Typical software for the region

A rather tasty target is software that is typical for the region. Here are some examples:

  • 1C-Bitrix (vulnerabilities, misconfigs, traces of exploitation);

  • Trueconf (CVE-2022-46764);

  • Terrasoft/Creatio (BDU-2023-04519);

  • Websoft HCM (BDU-2022-06939).

This is where regional specifics begin to affect. For some vulnerabilities there is no CVE, and accordingly, tools based on CVE lists begin to break. For example, the EPSS metric, the main essence of which is the citation of a vulnerability in the international information field. For us, a critical vulnerability in 1C-Bitrix is ​​terrible, but others have not heard about it.

Fig. 12 1C-Bitrix vulnerability

Fig. 12 1C-Bitrix vulnerability

Fig. 13 Trueconf vulnerability (CVE-2022-46764)

Fig. 13 Trueconf vulnerability (CVE-2022-46764)

If the criticality of finding vulnerabilities in 1C-Bitrix is ​​clear to most, since in May last year many were affected by a series of hacks and subsequent post-exploitation, then the situation with TrueConf is less transparent. Most likely, this was a class of software that none of the attackers paid attention to, but at the same time it contained a vulnerability. The situation was aggravated by the fact that this software is used in many serious organizations.

It is also worth noting that despite the large number of vulnerable nodes found, each of the vendors promptly notified their clients, which affected the threat elimination statistics. We'll talk about this further.

3. Often vulnerable technologies

Additional and perhaps less obvious, but no less widespread, are attacks on secondary resources of organizations, such as web cameras and various storage facilities. Very often, these devices are practically not updated, as a result of which they have very old vulnerabilities. We call them CVT (Common Vulnerable Technologies).

Here are examples of such devices, ordered by prevalence. Some also indicate the number of vulnerable devices (via /):

  • Mikrotik (CVE-2018-14847) – 94000+;

  • Hikvision (CVE-2017-7921, CVE-2021-36260) – 3000/75000+;

  • Dahua (CVE-2021-33044) – 10000+;

  • Xiongmai (CVE-2017-7577, CVE-2018-10088) – 900/10000+.

4. Ports with specific software

Once most of the common low-hanging fruit has been picked, you can move on to looking for anomalies on previously unknown ports. Consider the following ports with an anomaly:

The first of the anomalies was discovered thanks to a vulnerability in msmq 2023. When comparing the results SKIPA with Shodan and Censys it was discovered that this port was not scanned by competitors. It is worth noting that after some time they also paid attention to this protocol and, as a result, to the port. A similar example is the virtually non-existent detection of TrueConf software on port 4307.

Fig. 14 Statistics on the prevalence of ports 1801 and 4307 in Shodan and Censys

Fig. 14 Statistics on the prevalence of ports 1801 and 4307 in Shodan and Censys

Fig. 15 Prevalence statistics for ports 1801 and 4307 in SKIPA

Fig. 15 Prevalence statistics for ports 1801 and 4307 SKIPA

But what is hidden behind port 7547?

Fig. 16 Statistics on the prevalence of port 7547 and products on it in SKIPA

Fig. 16 Statistics on the prevalence of port 7547 and products on it in SKIPA

You may be surprised (we were surprised), but port 7547 is the most common in RuNet. Using technology SKIPA Statistics were compiled not only on the prevalence of this port, but also on the products that are located on it. Mostly they are associated with CPE (Customer Premises Equipment) class devices or subscriber equipment. Typically, these are standard devices provided by providers and operate using the CWMP (CPE WAN Management Protocol) protocol (which in turn runs on HTTP and SOAP). Since these devices are typical, as is their configuration, any potentially found vulnerabilities or misconfigurations put hundreds of thousands of devices at risk.

5. What they are trying to hide

If all the tactics and techniques listed above were not enough, then you can turn your attention to the services that Internet users are “trying” to hide. Usually this is adding a number to the standard port for a given protocol or software, or changing the port to an atypical one in the upper range. For an attacker, this is usually a red flag, indicating that you can listen to music there, watch TV, and go somewhere where you may not be expected.

Fig. 17 Some examples of resources that are “trying” to hide

Fig. 17 Some examples of resources that are “trying” to hide

results

So, we have tested many approaches, found a huge number of vulnerabilities, but the question arises – what to do about it?

Since in our practice we encounter various reactions from resource owners, from: “Stop it immediately, I’m contacting law enforcement agencies!” to: “Guys, let’s work together to eliminate vulnerable services!”, then I would like to share the organizational and technical conclusions that we came to and back it up with statistics.

Trending vulnerabilities: Fortinet

The most common case is wave-like software patching. The graph below shows the dependence of the number of vulnerable services on time in the Fortinet product (fortios). Peaks are the release of new vulnerabilities, between which there are recessions – periods of their correction.

Fig. 18 Dynamics of vulnerable services of the Fortinet(fortios) product

Fig. 18 Dynamics of vulnerable services of the Fortinet(fortios) product

Trending Vulnerabilities: Atlassian Confluence

Also, a fairly typical behavior that we can observe based on the Atlassian Confluence product is the rapid fixing of products followed by stagnation.

Fig. 19 Dynamics of vulnerable services of the Atlassian Confluence product

Fig. 19 Dynamics of vulnerable services of the Atlassian Confluence product

Compromise, vulnerabilities, backdoors in CMS 1C-Bitrix

Interaction on the 1C-Bitrix website management product was more productive both from the point of view of organizational measures and from technical ones.

Fig. 20 Dynamics of compromised and vulnerable services of the 1C-Bitrix product

Fig. 20 Dynamics of compromised and vulnerable services of the 1C-Bitrix product

During monitoring, using technology SKIPA, at the end of May of the previous year, a campaign was discovered aimed at replacing the content of many resources with the same type of content – this is the first peak, marked in yellow. Further, when interacting with colleagues from the 1C-Bitrix company, we discovered the first indicators of compromise, expressed in the form of backdoors located on infected sites – this is the second peak, marked in blue. Further, as a result of our full scan, more than 8 thousand vulnerable resources were discovered (vulnerabilities in the vote and htmleditor plugins). If you compare the ratio of vulnerable ones (green graph) to resources with a confirmed backdoor (blue graph), you can estimate the number of services that were responded to before the attackers gained a foothold. In addition, there was close interaction with hosters to notify clients. One of the last possible incentives for the most irresponsible to update resources was the use of TSPU, which bore fruit.
The second peak of confirmed backdoors that you may notice is an ongoing interaction with a vendor who had a strong interest in patching as many of their clients as possible.

The work on this product demonstrates the application of a disciplined set of organizational and technical measures that ultimately led to the successful containment and remediation of a threat.

Typical software for the region: TrueConf

A similar example is interaction with TrueConf. The figure below shows a graph of the number of vulnerable services versus time.

Fig. 21 Dynamics of vulnerable services of the TrueConf product

Fig. 21 Dynamics of vulnerable services of the TrueConf product

During interaction with SolidLab, as well as with the help of technology SKIPAall vulnerable services were collected, and Also potentially vulnerable software versions. Next, all the information was transferred to the vendor and, based on the dynamics of detection, we noticed a significant decrease in the resources at risk.

conclusions

As a result, the study allows us to draw the following conclusions, which everyone probably knows, but it is very important to remind them:

  1. Keep an eye out for new vulnerabilities.

  2. Know your perimeter so you can decide whether a threat is important to you or not.

  3. Act quickly if a vulnerability is discovered on your perimeter.

  4. Try not only to hide, but also to become safer.

Author: Igor Pervushin – head of the knowledge base creation department at CyberOK.

News

We also want to share good news for us and, we hope, for everyone reading. We are launching our flagship product SKIP. Presentation will be held on April 25 in a closed mode in the place of strength of the Russian cybersecurity – in Cyberdome. We will share videos and other content from the launch in our Telegram-channel. It's time to subscribe!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *