Testy bezpieczeństwa infrastruktury w przerwie na herbatę. Czy to możliwe?

Okay, let's start. Good morning, ladies and gentlemen. An excellent presentation. Replay of infrastructure tests during a coffee break. This time, I'm handing the floor to Krystian a little differently. Hello, yes, Krystian, the department head from this page, yesterday. I had the opportunity to present this presentation at a stationary meeting. Besides, so, I hope that today, those who weren't present, or even were, will have something extra for themselves. I've also prepared a small demonstration of what the tools we'll be presenting here, which we'll be using to present these infrastructure tests, look like in practice. So, you're welcome. Okay, agenda, agendas, but first, let's decide how long this tea break lasts. Well, as you could see somewhere in the

title, we'll be discussing the topic of infrastructure tests here, but for a more informal introduction, we can start with a less technical topic. That is, how long a

tea break lasts in different countries around the world. In fact, this tea break lasts, so when it comes to this, the most famous region, the most famous when it comes to the love of tea. Well, here I think that Great Britain is the first place that comes to everyone's mind. The time there lasts from about 30 minutes to an hour, in the case of the famous tea break, or even Two hours. I think this tradition is no longer cultivated, especially among people working in the IT industry, but maybe I'm wrong. Maybe there's someone who comes from that area or works for companies in Great Britain. The more popular teas there are, of course, English Breakfast, which is

black, interestingly enough, often with milk and sugar. I rather associated it with Bavarian tea. It was also popular here at one time, at least somewhere, from what I remember, among my parents. And there's also another popular one. I think it's also in Poland, which is Elay flavored black tea with bergamot oil. A tea break in Japan looks like this: there's a traditional tea ceremony, perhaps you remember it from some TV series, movies, etc. It can last even several hours. Daily tea breaks at work or at home are customary. Of course, they are shorter, similarly, probably, as I mentioned here about Great Britain, they last similarly, i.e. about 30 minutes to a maximum of an hour. And here, when it comes

to these popular teas, it's definitely also quite common in Poland for some time, i.e. Maa Senza and Gen. majza I hope that's how it's pronounced. We also have another country that's famous for its love of drinking tea, Turkey, where, interestingly, this tea is drunk boiling hot, from something I found somewhere at the source. Well, to cool down, you're less likely to want to drink, and drinking boiling water, I think that's the main point. These breaks also usually last from 15 to 30 minutes. The most popular tea is simply chai in three strengths. We won't go into details here, but I'm personally a fan of their teapots, so to speak, and also of those oblong glasses. It looks very

nice in Poland, in my opinion. Well, we are. Interestingly, one of the countries that is strong in terms of both the export of this tea, because we're probably in the top 13 in the world, and also in terms of consumption and drinking of this tea, so we don't have a tradition as such, like in Japan, where there's this choja hanja. However, here, this tea break is definitely culturally rooted, although it actually seems to me That's more likely if you work from the office somewhere. Well, I think it's more likely that a friend or colleague from the team will take you for a coffee break than for tea, as mentioned here at the beginning somewhere regarding popular

teas. Well, black, green, of course, also Saga in the iconic glass with a basket that we see here. Here on the screen: Okay, so we've determined how long this tea break lasts approximately in different countries where this tea is actually popular. We can then move on to a slightly more technical part, i.e., here, as you can see, we'll generally discuss how a security test itself works, i.e., what types of security tests we have, the methodology, automation, and a comparison of vulnerability scanners, which are tools that we'll also be presenting in practice. Everything will come out in the wash. A few words about me. My name is Krystian, a departmental employee. I've been working at Securitum for five years,

carrying out several dozen projects a year in the field of penetration testing, OSINT infrastructure, as well as WiFi, social engineering tests, and configuration analysis, which naturally results from the fact that I started as a Linux administrator. I'm also the author of the chapter. Nmap in penetration testing, an introduction to IT security, which will be released probably in September or October of this year by Securitum, a publishing house probably better known somewhere in there, the journalistic section. So Sekurak, if you have any questions after the presentation. Of course, I'm also on Bit Discord. There's also a link to my presentation posted on the main page. And here are the email addresses on LinkedIn. You can also write. I

try to be quite active and reply relatively regularly. Okay, so when it comes to the types of penetration tests, they can take a variety of forms, starting with social engineering tests. So, you could say, verifying employees' reactions to an attempted break-in, for example, into an office, or an unauthorized person trying to enter a server room. We also have specialists somewhere in the team who, as they say, entered the largest companies in Poland through the most popular web application tests. Here, as he specified somewhere, when it comes to penetration tests, you could say that this is the most popular area, and in many cases, you can notice that this area reigns supreme in terms of popularity, including in

online courses and so on. I think it's probably around 80 %, I'd estimate it somewhere around here, probably somewhere around there too. We'll have more and more of these mobile applications being tested here, their popularity will be increasing. We can actually end up with full external tests, as I described it, meaning with only the name of the attacked company. This is called redam. To systematize our view and introduce us to the types of penetration tests. What are the scopes, so to speak, in a sense, the types? We'll introduce the three most popular details here. Types. Have you heard anything at all? Do you know what this is about? Because it's not entirely clear what this phenomenon is about? We'll start

with Black Team penetration tests, meaning we really don't know anything. This is the Red Teaming I mentioned earlier. So, we really only have information about the name, and we simply have to hack it. As the dog in the attached video says, we don't know what this is about. Have you heard anything at all? Do you know what this is about? Because it's not entirely clear what this phenomenon is about? I do n't know what this is about. Okay, another type of penetration test. There's a Greybox that dumps information, revealing it. We only have part of the information, so to speak, it grants some permissions. As an example, we can use the wrong one here, but for

example, tests of web applications where we only get the user. For example, I don't know the application used to book a doctor's appointment. This will also be an example in the next case, and we only have the account of such a standard user. Our task in the case of GreyBox will be to raise the permissions of this user to a higher level, for example, to the level of an administrator, simply to the level of a privileged user. The last type of penetration testing will be whitebox, meaning we know everything, we have full information from the client. I hope it's from the client, and we have all the necessary permissions. For example, tests of the administration panel of a web application

used to book doctor's appointments from the level of the admin account. I think there's nothing more to add, nothing less. Infrastructure tests are generally quite vague, a rather general concept. If we're talking about infrastructure tests, they cover both publicly available networks, i.e., the VAN, and local networks. We'll do a short reminder in a moment. Or simply acquire basic knowledge about this division. Generally, penetration tests involve identifying as many networks as possible, and in this case, it's also similar. We identify as many vulnerabilities as possible in the client's infrastructure, and this can apply to both web applications, which we've already mentioned several times, as well as phones and printers shared only on the local network. I also include OSINT

reconnaissance and resource reconnaissance in infrastructure tests. I simply consider this an integral part because I believe that without it, well, it's simply something that's necessary in this type of testing. Van network tests in English are Network. As a prime example, we can give the Internet network in short. Tests of hosts that are publicly available in the Internet network. The number of IPv4 addresses that are publicly available, because here we're talking about IPv4 in this case. Well, it's a really huge number. Although, as some people probably know these IPv4 addresses are running out. It's been said for years that IPv6 will take over the role of IPV4 somewhere, but I think there's still a long way to go. There's still a

lot of water in the river. For example, here, such tests on a public address can be used to simply receive an order to test the Van infrastructure on a domain address, so here I have almamater as an example. you could say sekurak.pl where we quickly identify the IP address of this website and we can start a scan here, penetration testing of the publicly available IP address to which this very domain sekurak.pl resolves, LAN network tests, i.e. Local Area Network, something that each of us also deals with on a daily basis, because in fact, somewhere even operating in home network conditions, also although there it is more detailed, it is called personal area network from what

I remember, but also each of us probably has our own network, a WiFi network at home, where we also receive this private IP address from such devices, routers and so on. So, naturally, each of us has several of these local IP addresses, so here we also have such a specification when it comes to address class ranges, as I said, a reminder of the basics here, and in fact we have classes A, B and C, where it seems to me the most popular, the most popular addresses that each of us has probably encountered somewhere. These are the addresses from class C that are most frequently assigned, but this is just my reflection, that I think this is the case

when it comes to the total number of these local addresses. So, There are about 18 million of them. I think so, I think so. Based on my experience, I have this reflection: LAN network tests are much more extensive than VAN network tests. Well, as I mentioned somewhere, maybe this isn't a flagship argument, but there are fewer and fewer public IPv4 addresses. They're running out, but I don't think it's the main argument. The main argument is that in companies, both large and small, the generally accepted standard is to place as many services as possible somewhere on the networks. Of course, another issue is whether or not these services and devices are made publicly available later. In

some cases, they shouldn't be. But they are, but that's the case. I think that's a topic for a separate presentation. Here's an example from my own experience with the tests I conduct every day. Specifically, infrastructure. What does the number of hosts we receive look like here? The addresses we receive for testing in the case of LAN networks, and in the case of VAN networks, this is an example from last month. Somewhere, of course, these addresses. This VAN public address, in quotes, is made up. I took it from Microsoft's pool somewhere and masked it like this. Well, in the case of VAN networks, there are a full 8,500 of these addresses. Is it a lot or a little? I think it's

quite a lot. The largest project I can remember testing a publicly available network. It was actually something that was also very impressive because there were probably 40,000 IPV addresses. And it's actually an incredible challenge to test such a large number of addresses. It's a kind of inventory, you could say, of the client's resources rather than the tests themselves, at least on a basic level. But it's also definitely an interesting challenge in terms of how to approach such tests, which we'll discuss in a moment. How does the standard process of conducting these infrastructure tests generally work? What does the methodology for conducting such infrastructure tests look like? I think we'll talk about it in a moment.

If we're starting an adventure with some type of testing, or generally, I think with work. Well, we need information on how to do it, we need instructions, we need some kind of recipe, and in the case of web application audits, well, there's a lot of it, I'm referring to those things again. Because, as I said, there are many of these methodologies. There are many, the most popular, such as top ten, such as mitre and st. And in the case of equally extensive infrastructure tests, I think they're often even more extensive than these application tests. Web applications, of course, depend on the reference point we take. As in every case, there are practically no similar documents.

I think these are rather studies prepared not by large organizations like OWASP, but by some small organizations or even private individuals on GitHub. I think there is definitely something, for sure. I know that there will be, among others. Besides, when preparing our methodology, you could say it's an internal one, which we use. Of course, they were based somewhere on such standards as OWASP. But it is a completely different type of test. It can be a methodology for performing infrastructure tests. Why is it that there are no such generally available methodologies or there are very few of them, they are quite niche. I think it results precisely from the fact that, firstly, these web application tests are

simply more popular. In fact, as I mentioned, web applications are, you could say, in the area of ​​this infrastructure, you can say they belong to the ICT infrastructure, so I think that due to the fact that these infrastructure tests in the general sense are less popular, these methodologies simply do not exist. So, we have come to an understanding of what it will look like, what will such infrastructure penetration tests look like? This is what an example methodology for their execution might look like. Briefly, without elaborating, of course, because there's quite a lot of text here, but I also distinguished three stages: one could say, conducting such infrastructure tests. The first type is actually passive reconnaissance, which is something I

mentioned somewhere else earlier. So, in fact, we can say that when it comes to this first stage, we use tools like Sodan, like the Total virus, and various variants of Shodan. In this case, we can say that it is a search engine based on a principle similar to Google therefore we have an aggregation of all such IoT devices. As the saying goes, that is, those with these public IP addresses. The Total virus is also a tool that is used in this case for a reason, because the Total virus may be associated with a tool that is used rather for such tests for file checking purposes. It is, so to speak a kind of virus scanner available

online. It also has a lot of information, for example, about subdomains, so it is also a very valuable tool in the case of passive reconnaissance. There is also active reconnaissance. Generally, in the case of passive and active reconnaissance, we are talking about the distinction that in this case, this first stage, these tests are actually undetectable, while in the case of active reconnaissance, this type of tests can be detected by the client through their own software. For example, this is also a risk here: exploitation, i.e., attempts to use the vulnerabilities identified in the two previous projects. This is, we can say, the heart of KOR. As we say in English, they are lurking in these tests of the Van infrastructure because

this is actually the goal of our tests, i.e., exploitation. In short, this is precisely exploitation, exploiting the vulnerabilities found in the previous two stages. We use many tools for this, such as MET, which have their own databases with these expi. This can lead to exfiltration, ending, for example, with access to the LAN. And that's all, really. Regarding the issues of these tests, Van network tests, we will now move on to an analogous process to the analogous methodology of

LAN tests. We take a break for a tea break and move on. Reconnaissance of subnetworks uses CMP and ARP protocols to detect the subnetworks used by the client, as we saw earlier in the previous section. In such a project, it's standard practice to identify IP addresses that I encounter somewhere, along with projects I conduct security audits. We receive a lot of IP addresses in LAN network tests. In fact, no. The first stage we care about is identifying and detecting as many active hosts as possible. I emphasize " active" because it's also a bit of a challenge. At this first stage, we conduct an inventory of the client's network resources because we need to know which

hosts we have from the range we received are active and have open ports. Without going into issues like the so- called Freeway handshake, i.e., the three-way handshake in TCP, where these differences also exist somewhere, and without going into even more detail about issues that I also discuss in the chapter that will be included in the Security book on NMAP, i.e., detection in the case of NMAP also when a host, for example, does not respond to the ICMP protocol. So, if the popular ping (for example, if some local IP address does not respond to ping), and yet this host is active, as I remember, in the case of Windows, for example, ICMP is disabled by default. so in this case

we also have to pay attention to not rely only on icmp, that's why he specified the second protocol here as an example because there is obviously more of it, i.e. ARP, which somewhere allows us to identify, in addition to such a test using ping, these active hosts in the local network, service discovery, i.e. we scan ports, here it actually overlaps with the previous slide with the methodology in the case of We scan ports to identify active hosts detected under networks. We detect services such as DNS servers to detect active domains with applications to detect, also in the case of a Windows environment, domain controller domains, for example, and other protocols that will facilitate us, one could say,

full exploitation of this LAN. The final stage i.e. exploitation, similarly to the case of the Ban network. However, here we are dealing with, of course, greater threats, which are, for example, the takeover of a domain controller. Well, this is a prime example, which is always... Here we give you a reference to these LAN tests as the main goal, as such the main challenge that we face in the case of, of course, the Windows environment, although of course not only... yes, when it comes to the next, actually here... another type... when it comes to the next... another issue that we will talk about here... we will actually try to answer the question included in the title of the presentation, i.e., whether it

is at all possible to perform automated infrastructure tests during a tea break, also during a coffee break, because it will probably overlap here in terms of the time we devote to them. Just for a break. Well, I could actually end this presentation and answer no, but as you know, I have a strictly defined time frame, so I'll try to use it to the fullest and show you what such an automated infrastructure test could look like in practice, and how clients often perceive these automated infrastructure tests because I'm also referring to such live examples from commercial work.

And when it comes to these tests, let's be honest. When it comes to automated infrastructure tests, it's perceived as being associated with the use of vulnerability scanners. So, in fact, the most popular solutions on the market are NUS and OpenVAS. These are the two most popular solutions. I also mentioned Qual here as another server vulnerability scanner and Rapid 7, but in the case of Qual, from what I remember, it was with this tool that I received a proposal to schedule a few meetings. Because I'm an IT professional, I don't like meetings, so I simply gave up on this topic in the case of the first two scanners. It's very simple, you could say, to get access to the

trial version, or to the trial version. In the case of NUS OpenVAS, it 's free. The installation process itself is also quite simple for Anyone who has basic knowledge about Linux, both in the case of Debian, Debian-like distributions, and from what I remember in various other variants, such as systems derived from CentOS, because now it's probably called Ry Linux, i.e. from Red. Well, it 's not complicated either. Rapid Se also didn't really get such an answer in the last two weeks. How can I get access to the trial version of this tool, so I just gave up. I focused on the perspective of a person who was just starting their adventure with these infrastructure tests and would simply like to

test a few tools comparatively, check what results each of these tools will give. Well, as I mentioned here in my presentation, I will focus on the first two tools, i.e. OpenVas and NUS.

Okay, when it comes to the issues of what's inside these vulnerability scanners, so to speak, these are, as it's often said, "mabyły" so somewhere there, our in this language, it, so these are tools that contain a lot of other tools. So you could say that they are A kind of aggregator of these tools also have their own databases of vulnerabilities, as I have detailed here precisely the CVE because it is one of them, one could say, the most well- known database of vulnerabilities publicly known in security. And here he used one of the articles on the Intruder website, which, by the way, very extensively discusses the differences between these two vulnerability scanners. How do they also use these

CVEs? The number of annually published vulnerabilities. Let's say that here, just to show how it looks. Something happened here, now it should be okay here, just to illustrate how large the scale is. The vulnerabilities released annually, we can trace this process, this cycle to 2010. And we can see that practically speaking, we are already reaching those 20,000, I think that it already looks like this, because here, until 2020, we have statistics even above 20,000 publicly published vulnerabilities. The number of CVMs as of today, here, in fact, is over a quarter of a million vulnerabilities, which is a very large number, as you can see, of these vulnerabilities. High severity is the most common, also about this medium vulnerability, i.e.,

medium. Well, there are, let's say, three times fewer so-called critics here than the two most overlapping ones, but anyway, it's a lot because in the case of critical vulnerabilities, we're talking about a really serious threat. CV coverage by both scanners. We'll just go through the charts from the Intruder article. Here we have information on how much it is. There's data for 2023 on how many CVs each scanner has. In the case of Table, i.e., Nusa, I'll add here because that's how it's called. In this article, we're dealing with almost 50,000 of these CVs that are in the database of this tool. In the case of Open, it's over 3,000, so we also have a percentage

breakdown, and in terms of percentage, yes, it's in relation to the total CV coverage for 2023 and in terms of shared and separate coverage. Here, too, for those interested, I invite you if anyone really wants to gain a deeper insight into the differences between these two scanners. Why is CV coverage so low, I don't deny that this is it. There's Saj, who I added, intrigued, inspired by a question from yesterday's presentation. As I mentioned earlier, today we're having a little extra time. Why is CVE coverage not even 50 %? There are several reasons, mainly CVS. It 's not the only source of vulnerabilities used by these scanners, both Open and Open, and they also use the vulnerability databases of

individual service providers, software developers, or devices, as in the case of Cisco. Not to mention the process of creating a plugin to integrate these new vulnerabilities into the scanner database takes time. The process includes vulnerability analysis. You can read on the NUS website how it all looks. It's not like CVE is coming out, like the recently popular topic, a lot of CVE on SSH, i.e., in a popular service for remote connection, which Karol Szafrański also talked about yesterday. A very interesting presentation, which I also recommend, about hardening these services, also based on SSH. There was also talk about SCP and SFTP, of course. Well, here we can really say that it's no wonder that this coverage is so low. It takes

time. It requires effectiveness testing. So,

we want to have as few of them as possible in the case of such tools. I also think it's worth mentioning that the priority of these vulnerabilities in terms of severity is also important, which is why not all of them are covered by these CVEs and many SPs. CVEs are simply not exploited. I managed to pronounce it the first time. Not exploited remotely. They concern specific systems, such as skada related to itot, and also the technical capabilities of the tools may be limited by licenses and copyrights. The total number of CVs until January 2023. Well, here we also have approximate coverage from this Intruder article, we also have here coverage in each of the risk levels in each of these, in each of these

comparisons, you can say strictly concerning CVEs. Practically speaking, NUS wins, which I think is also quite characteristic coverage of remote CVEs, so we are talking here about such, as we mentioned somewhere earlier, CVEs that concern public and local networks, de facto, which will work, these EKLO in this case without authentication. So we can say that this is important precisely in the context of tests such as, for example, ring tests, where we only have And only the client's name, and we have to simply hack the company. The chance that the first check will be a remote check. Well, here we have information somewhere about the percentage chance of this first remote connection. We can say this about

these CVEs. And the conclusions from the comparison, as you can see, NUS reigns supreme. This is no surprise to most people who are familiar with these tools, but NUS is a good tool for certain purposes, which we will also discuss in a moment. It has a commercial offer that is a market leader. Open takes second place in most analyzed areas, despite everything. I believe that Open can also be used successfully. In certain conditions, for example in smaller networks, for the so- called Vulnerability Assessment, one could say that such a translation into Polish is missing here. Simply put, such an inventory of these vulnerabilities is missing. These are just numbers, so in practice, we also look at the reports

that present OpenVAS and NUS on similar applications at similar addresses. In fact, what distinguishes NUS, apart from its effectiveness, is its simple operation. From my impressions, however, running such a test that will be analogous to NUS Open requires Let's be clear, we need two different types of tests: the interface appearance for this NUS. This is what the interface looks like for this NUS Professional. It's similar for this free NUS, NUS Essentials. The interface appearance here offers configuration options, including various types of scans. Among other things, we also have the ability to perform local tests that will verify our configuration on the host where this NES is running. So, if we give it access data, for

example to SSH, it can check the configuration of the operating system according to the so-called CIS benchmark. The interface appearance, selecting the target, here we have a presentation of what the configuration actually looks like. This is possible, this scan can be performed from the NUS Pro level. The nuances of the configuration in the case of the so-called advanced scan, we can simply set the full range of ports and also test web applications. We have information here on how we can also adapt these web application tests to our goals. The interface appearance in the case of Open WAS is a bit uglier. In my opinion, I personally don't like it; I prefer a darker skin. Perhaps there

is a possibility to change it, but I haven't verified it. If something is missing, I simply tried to verify both tools for a beginner security researcher, a beginner pentester who would simply like to run an automatic vulnerability scanner as quickly as possible and at the lowest possible cost.

Here we have an example of just such a tool, similarly to the case of NUS, as we saw here, we have such a window in the case of Wą Toi SP, the result of this advanced test, Advan Scan Wes. There are some of these options here, we have the option of a full scan. Fast is it actually fast or full, that's a matter of debate. We'll talk about that in a moment. What is the issue of configuring such a target? Open, it's more complicated. Here are a few words about the differences between NUS Essentials and Pro, i.e., what are the differences between the paid version of this, you could say, the best vulnerability scanner? I'm not afraid to

say it because generally NUS is a better tool. It allows you to scan up to 16 IP addresses. If we're talking about the free NUS Essentials, it also cannot be used for strictly commercial purposes. It displays the number of vulnerabilities without elaborating on them, so to be a bit more specific. It's simply that in the case of the paid version of NUS, it aggregates, as it were, In one vulnerability, several different ones. Maybe in a moment we'll show you in practice what it looks like. I have NUS Essentials installed, so I think we can show you what this interface looks like, more or less. How the reports from this NUS also look like from OpenWas. Well, let's move on

to a short demonstration of these reports that NUS and OpenWas spat

out at us somewhere. Of course, I can't log in now. Okay, we managed to do it. Here we have the scans that I performed also in the case of OpenWas. Here is Inter Open. Here we see the NUS interface. I used hosts that are shared by Akune, which are simply intended for such testing. And as we can see here, we have 40 vulnerabilities. A nice chart that shows us how many of these vulnerabilities were found. We have information here on various topics, because in fact, we also have information here about how long this scan took. We have information on what it is based on when it comes to determining the severity of these NUS vulnerabilities. And in the

case of the free NUS, as I mentioned, here we see there is one vulnerability, but Count 19. So we actually have here in this one In the folder with 19 different vulnerabilities, it also counts them for different addresses, of course, but you can see that there are more of them here, yes, we have several of these vulnerabilities, it's not just one vulnerability. This can be misleading in this context, as it may seem that NUS will immediately list NUS Pro, immediately list all these vulnerabilities here. And then we will see information somewhere there that there are more of these vulnerabilities, i.e. around 60 or so. But if we figure out the same thing, NUS Essentials, I emphasize NUS Pro, it's the same

tool, only the free NUS has a limitation in the ability to scan up to 16 addresses, so this is what it looks like. In this case, we can download the report, it's simple, we will receive the report here in the form of an HT file in the form of an HTML file. We can also export it to PDF or CSV. And this is how the report prepared by NES will look like. Of course, we have information that it is NUS Essentials on every page. We have all the vulnerabilities listed by a given host, so in reality, we have it all nicely aggregated, and maybe we won't be very I don't want to go into details, but in my

view it's quite clear. Of course, it's raw. We have mainly technical information here. That's what it's all about. That's what the reports from these vulnerability scanners are all about. Yes, that's what they look like. But as you can see, we also have information about sources somewhere, where we can get more information about a given vulnerability, for example. So I think it's really a form. And such a report can definitely be used to systematize our knowledge about the infrastructure. Okay. Now let's see what it looks like in the case of Open Source here. As we can see, I also conducted scans on the same ones. In the case of NUS, here, on all the pages that

we can test somewhere, which are publicly available. Thanks to akune xwi. No. As we can see, in my opinion, it looks a little less intuitive here, so that, from what I remember correctly, we can also develop other, other, log-type vulnerabilities, so in the case of NUS, it's called info, so informational. So we need to remove the filter here. And here, when it comes to the ability to download this report, we have several of these formats. No PDF, no HTML, but I think PDF is also fine. We'll download it. This report was immediately displayed in the browser. And this is what the report looks like. We can compare NUS. In my opinion, it's less readable. This table format doesn't really appeal to me. I

prefer a summary like NUS personally. But you can say that it also fulfills its role, defined in this way. What catches the eye is that OpenVAS doesn't handle web applications very well. I simply assumed that I would be testing. And as you can see, here we have significantly less information. We have some information points regarding, for example what this point concerns, for example, http server banner enumeration, which shows us information about the software version used. And here I also think that these points are not entirely readable. It could probably be made more clear without this information, maybe about the quality of this detection and so on. However, I think that in general, OpenVAS also loses to NUS in this respect.

However, we must admit that when it comes to OpenVAS, there is also a tool that will give us an overview of the vulnerabilities that are somewhere in our network on the tested hosts, but we also need to perform a second type of scan, i.e. CVE, which I mentioned earlier, in the case of NUS, it's done automatically. However, in the case of Open Base, we simply have to run the second type of scan. It's just a little more clicking. It's not particularly problematic, but you know, time is money. Time is money, especially in the case of penetration scans. Where sometimes the scope of these scans is truly astonishing. We have information here. This will probably coincide with the CVE that

NES found, of course, but from what I remember, there are fewer CVs here regarding, for example, PHP. So, vulnerabilities related to PHP. At first glance, I don't know if I'll be able to find anything here. [Music] No, I don't see any vulnerabilities specifically related to PHP. We have information here regarding, for example, Microsoft. We have information about PHP here, but at first glance, OK, I don't see anything. I also think it's fair to say that it loses in this respect, but from what I remember, it has finds in quotation marks that NUS didn't find for us, so what can we do? We can simply combine both tools and check the differences, test for whether, for example, Open Base will not detect more vulnerabilities affecting the network layer, because I think that in this case, Open Base will not detect any vulnerabilities

affecting the network layer, because I think that in this case, Open Base will not detect any vulnerabilities affecting the network layer. was doing better. And as for NUS, well, as you can see, it also handles web application tests.

List how well all of these are not so- called false positives, but still, some general overview of this infrastructure is also

given here by this NUS. And it looks like My virtual machine froze, so these are the joys of running two vulnerability scanners [Music] on one virtual machine, but we're basically getting to the end. I see that it probably wo n't be possible to cut it off here in the summer, so maybe in a moment I'll also post the doc [Music] here, just from another window, this presentation, so give me a

moment. OK, in the meantime, when I started running [Music] it cut off, so [Music] fantastic, we can go

on. So I also wanted to present you here a sample report from comparative infrastructure tests, so you can see So, how does it look in practice? So, from what I see, we still have 7 minutes. I think we can review this report here, we can compare it to what NUS and Open spit out somewhere. I'll schedule each point here. I just want to show you how we write these reports, how these infrastructure tests are described somewhere, as you can see here, specifically regarding the methodology. We call it our internal security testing methodology, Securitum, and here, somewhere, there's a vulnerability classification. You can read how we classify these vulnerabilities also in relation to specific companies and organizations. Of course,

this report is anonymized, so you don't know which organization we're talking about, but I think it also gives a general view of how these reports are prepared by us.

Here, of course, we have a table of contents, so I think that's not surprising. And the first point, which is a vulnerability estimated at High. We have information about the CV that the auditor managed to find in the case of the Apache web server, version 2457. As you can see, here's information about the conditions necessary to use There are no conditions for the vulnerability because these are tests of the VAN network after installing such a server in this version. It is normally susceptible to these DOS-related issues. What is worth knowing? Additionally, as you can see here, what I mentioned, the auditor has already broken away. It can be said that to some extent this report could be

based on NUS. Perhaps NUS was also used here to find these vulnerabilities. However, as you can see, this is a bit of out-of-the-box thinking. I said a bit of out-of- the-box thinking because we are using another vulnerability here, like SL Loris. In fact, we have here a "d" in one. This is already something that NUS or Open Source will not perform for us. So, this is something that is here, we can say with this unconventional thinking. Okay, and here we have the technical details. Proof that this vulnerability exists. Sending a large number of queries. Or, you could say, testing how this server will react. As you can see, after 912 calls, the server simply stopped accepting new ones.

You could say, as they say, that it crashed. And that's really all there is to it. In the case of production servers, it could be very, very problematic, so that's why it was removed. Estimated at... I think not at a critical level, because we're not dealing here with, for example, the filtering of confidential data, but it's a significant vulnerability nonetheless. Of course, here we have a point that, as standard in network structure tests, is repeated quite often. That is, simply these problems with SSL certificates. I think it's worth reviewing this report from this perspective, to simply verify how everything is configured in your case. Each such report provides, in a sense, an overview of what vulnerabilities

may exist in a given infrastructure. What I wanted to say is that the report we send to clients as standard, which clients receive, is simply much more comprehensive, and at this level, one could say, not technical, explaining step by step how a given vulnerability affects the infrastructure, how it also affects companies, because we're pressed for time. I think we can stop here, as I already said. To sum up, I showed you somewhere what these scanners can do. First of all, I think we'll answer this question in a moment. To sum up, these vulnerability scanners can fulfill their role in the case of management and inventory of these vulnerabilities. However, in the case of automated infrastructure testing, I simply wouldn't

call it penetration testing at all. This is my opinion. Exporting vulnerabilities from Nusa C to Open is not penetration testing. So, yes, here, can scans performed using Nusa BD Open, as I said, be called full-fledged infrastructure testing? No. Can they be called automated infrastructure testing? Maybe a little yes, maybe a little no. Of course, many things can be bent here, but probably not as much as here. We have the famous answer from 10 somewhere. Can infrastructure testing be performed during a tea break? Three times. No, thank you very much. I hope that if there are any questions, you will answer them somewhere outside the presentation, because I see we are almost finished. Thank you very much and I encourage you to

contact me. Present. The agenda for today is really very strong starting this morning. Thanks, thank you very much, and we invite you to our lunch break. See you in an hour and a half.