CompTIA Pentest+ PT0-002 – Section 4: Passive Reconnaissance Part 6

34. URL Analysis (OBJ 2.1)

URL analysis. Now, at this point in your career, you should know what a URL is. A URL is a uniform resource locator. It’s that little address that you type and the top of your web browser to get to diontraining.com or comtia.org or whatever other website you want to go to. Now, a major portion of a cyber security analyst job is looking at different URLs in a proxy log, or other security logs to determine what websites have been visited and what type of data has been passed to those websites.

It’s our goal to get by those analysts and it’s important to understand what they’re looking at in their logs to avoid detection. Now URLs have the ability to encode some action or some data, and that can then be submitted to the server during the request. When an analyst conducts a URL analysis, this is basically just an activity that’s performed to identify whether a link is already flagged on an existing reputation list and if not, to identify what malicious script or activity might be coded within it.

Now this is important because there’s some encoding that can happen inside the URL and so the analyst needs to use the right tools to be able to resolve that percent encoding that might be there. Assess what sort of redirection the URL might be performing and showing the source code of any scripts that are called by the URL without executing them and they want to do all of this inside a sandbox environment, so they don’t effect their own machine. Now let’s take a look here at a simple URL and I say simple but it’s not really that simple, you can see how long it is here on the screen.

It’s Diontraining.com/upload.php?post= and then this long thing. Now, as we go through this lesson, we’re going to come back to this URL quite a few times, but first, before we start analyzing it, we really have to understand some basics of URL analysis. That way we can better understand this URL and see what it’s really good or bad or there’s some kind malicious thing going on. Now, there are three things we’re going to talk about in this lesson. We’re going to talk about HTTP methods.

We’re going to talk about HTTP response codes and we’re going to talk about percent encoding. First, what is an HTTP method? Well, this is a set of request methods that indicates the desired action to be performed for a given resource. Now, when I talk about a resource, essentially think about that as something on the server, could be a webpage, an image, a file or something like that. Now a request is going to contain a method, a resource, a version number, the header, and the body of the request. We put all that information together when we send something out through a URL.

So when you go to Diontrain.com, you are actually sending an HGTP method saying, please go to this website, get the page and send it back to me with the body and the header and that’s what our server does. Now there are many different methods that we’re going to talk about here, the first one is get. A get is the principle method that’s used when you do an HTTP request and it’s used to retrieve a resource. So again, when you go to Diontraining.com you are using a get, saying get me that page, get me the index page of that website.

The second one we have is a post, and this is what you saw in the URL I showed you earlier. A post is used to send data to the server for processing by the requested resource. So in the example I had, it was the upload. PHP file and the action was post. So we were sending data to the upload.PHP file, which is a script that would then be run on that server. Next, we have the put method, and put is going to create or replace the requested resource. So if I put a file on the server, I’m going to upload it there and overwrite what’s existing.

The next one we have is delete. This is used to remove the required resource. So if I wanted to delete a file, I could use the delete command. Then we have head, head is going to retrieve the headers for the resource only, and it’s going to ignore the body. So if I send out the head command to the server, I’m only going to get the head portion of the HTML and not all the body. This is often used as a penetration tester when you’re doing a banner grab, ’cause all you want to know is information about the server and about the page, like the title of the page.

Now data can be submitted via a URL and it’s going to be delimited by the question mark character. You saw earlier when I had my upload.PHP, there was a question mark there that then said post equals and that was saying for this resource, I want to do this next thing, I want to post and that’s the idea here of submitting data via a URL using that question mark character.

Now you also have query parameters and query parameters are usually going to be formatted as one or more name equals value pairs and they’re going to use an Ampersand delimiting each pair. So if you think back to our Google hacking lesson, we use the ampersand to connect different value pairs together, as we sent them to Google to do a specific search.

Now, the next thing we want to talk about is a hashtag and a hashtag is used to indicate a fragment or an anchor ID and it’s not actually processed by your web server. If you’ve ever coded HTML, you’ll know that you can use a hashtag to say this is a particular part of the page. For instance, if a page is longer than what can fit on the screen, maybe you have a very long book that’s in one webpage. I can actually have a hashtag to show where those anchor points are for each chapter and then when you click a link at the top of the page, it would take you directly to that portion of the page and jump down.

Again, it’s not processed by the server, but you should be on the lookout for these as part of your URL analysis because sometimes people will misuse that hashtag and inject JavaScript into your page by using that as part of the URL. So let’s look at the URL one more time. Here you can see the post method is being used, like we talked about this is going to indicate that we’re sending data to the server for processing by the resource.

In this case, the upload.PHP script, which is sitting on Diontraining.com. Also you’ll see there’s that question mark there, that is being used to indicate that data being submitted to that page is going to use the post command and its values after the equal sign. Now all that stuff after the equal sign, we’re going to talk about that in a little bit. We have some more stuff to cover first. Let’s go ahead and talk about HTTP response codes.

Now out when you deal with an HTTP response code, the header value is going to be returned by the server when the client requests a URL and these different codes are numerical codes, usually three digits that are going to tell you some information that the server wants you to know. For example, if you get a code 200, this indicates a successful get or post request, meaning you went and got the page and it came back to you successfully.

If you get a response code of 201, this indicates that your put request has been successful in creating a resource. If you have a response code of 300, anything in the 300 range, this is going to indicate a redirect has occurred by the server. For example, there’s a 301 redirect that we use when we move a webpage from our site to a different site. So that way we tell Google that we want all that information they know about that old page to be transferred to the new page.

That’s a 301 redirect. You don’t need to know all the codes for the 300 series but you should know that 300 and anything is going to mean that a redirect has occurred by your server. The next series we have is the 400 series and this indicates that you’re going to have an error in the client request and there’s some specific ones here that you should know. The 400 itself is going to indicate that a request could not be parsed by the server. If you have a 401, this indicates the request did not supply the authentication credentials.

If you have 403, this indicates that the request did not have sufficient permissions to access that thing. If you have a 404, this is very common. It indicates that the client has requested a non-existent resource. The next series we want to talk about is the 500 series and a 500 series has any code in that area, means that there is some kind of a server side issue.

Everything up to this point was really a client not getting what they wanted. Now we have some server side issues. A 500 is going to indicate a general error on the server side of the application. A 502 indicates a bad gateway and you’ll often see this when the server is acting as a proxy. A 503 is going to indicate there’s an overloading of the server and that’s going to be causing service unavailability and a 504 indicates the gateway timeout has occurred and this means there’s some kind of an issue with the upstream server. Now for the exam, you do not have to memorize all of these error codes, but you should be aware of them in your role as a cyber security analyst inside the real world because you’re going to be dealing with these, especially if you’re dealing with web applications and web application testing.

Now let’s go ahead and look at our URL one more time here. Now does knowing those loads help with identifying anything in this URL? Well, not really, but if we tried opening this URL on your web browser, you would get one of these codes back. You would get a 404 error. Now, what does that mean? It means the page doesn’t exist. Why is that? Well it’s because the requested resource, which was the upload.PHP can’t be found, now why can’t it be found? Well, because I made up this URL.

We don’t actually have a page on our website called upload.PHP on our server but there’s still a lot in this URL that we don’t know, everything after the equal sign we haven’t even looked at yet and that’s going to bring us to the concept of percent encoding. Now percent encoding is a mechanism to encode 8-bit characters that have a specific meaning in the contact of a URL. This is also known as URL encoding. Now a URL can contain unreserved and reserved characters from the ASCII set. Unreserved characters are things like letters and numbers, A through Z, zero through nine. It’s the dash, the period, the underscore, and the tilde. Now we have some reserve characters as well.

These are special characters like the colon, the back slash, the question mark, the hashtag, the brackets, the at sign, exclamation, dollar sign, Ampersand, single quote, parentheses, star, plus, comma, semicolon and equals. All of these are reserved characters. You can use these inside of a URL. There’s nothing wrong with using them but they do have a special meaning. For instance, we talked about the question mark already. We’ve talked about the ampersand. We’ve talked about the equal sign.

All of these are special characters or reserve characters that can be used inside your URL. Now a URL cannot contain any unsafe characters. Now what’s an unsafe character? Well, these are things like null string termination, carriage returns, line feed, end of line, tab, space and things like the forward slash, the less than sign, the greater than sign and the curly brackets. All of these are characters that are considered unsafe and cannot be used in a URL. Now percent encoding is going to allow a user-agent to submit any safe or unsafe character or any binary data for that matter to the server within a URL.

So if I want to send a space, I can do that if I encode it with one of these percent encodings. Now here’s where I need to bring up the warning. Warning, warning, warning, percent encoding can be misused to obfuscate the nature of a URL and submit malicious input as a script or binary or some other method like that to perform directory traversal and other bad things. So when you see percent encoding, you probably should think to yourself, there’s probably something being hidden here. I need to look further into this. Now let’s take a look at percent encoding and here on the screen, you’re going to see a chart. On the left, you’ll see the characters and on the right, you’ll see the code. Now. I’m not going to read them all to you but you do have them here on the screen and you do have them in your notes, in the PDF study guide. Now, the thing I want to point out here is that this is not a list of all of the percent encoding.

These are just some of the most common ones that you should know and be for familiar with. There are many, many others. When you’re an analyst in the real world, I do recommend that you print out a PDF that has the entire list of these because you will use them in your URL analysis. For the exam, you do not need to memorize all of these but you do need to know a couple of them and we’ll talk more about that later.

Now, some really tricky attackers have started to do what’s called doubling encoding, and they can double encode the URL by encoding that percent sign too. So when you’re looking at the URL, and so you won’t see something like %20, even though that theme will be percent encoded. Now for the exam, when you see a URL, if they want to talk about URL analysis and they want to talk about percent encoding, they will use the percent sign. They won’t do the doubling encode, but I want you to be aware of that ’cause in the real world, this is something you have to be aware of.

All right, one more time, let’s go back to our URL. Here again we have our URL, Diontrading.com/upload.php?post=. We’ve talked about that. This is the website we’re going to, the file on that website and the action we’re going to do. We’re going to post something. Now let’s get into what we are going to post. So if we look at the URL again, we have %3Cscript%3E. Now what is 3C and 3E in percent encoding?

Well, if we go back to our chart, you would know that %3C is the less than sign and %3E is the greater than sign. So essentially this is saying post equals bracket, script bracket in HTML. Now, if you know anything about HTML, you know that bracket script bracket means we’re calling a JavaScript and so that is something that we need to think about of what script is being called and that may be something bad. So let’s go a little bit further into this. The next area we have %27http%3A%2F%2FABC123.com, %2Frat%2Ejs. What does that all translate to? Well %27 is a single quote mark. %3A is a colon. %2F is a back slash and we have that twice and then %2E is a dot.

So if I was going to read that without the percent encoding, I would read that as single quote, HTTP://ABC123.com/rat.js and so now you can see what this URL really is saying. It’s saying go to Diontraining.com, access the file upload.PHP and post meaning upload send this file of script, this website address with a link to Rat.js. So we’re trying to send this file, this JavaScript file to this site, and if it was vulnerable, we could then upload malicious code. That’s how we do this URL analysis and for the exam, you are going to be asked to do some URL analysis. Now, let me give you an exam tip for this area of the exam, we talk about URL analysis.

You don’t need to necessarily remember the values for all of those percent encodings, but you should know what it is if you see percent encoding. It is some kind of a URL analysis question and you’re probably going to be asked to try to figure out what they’re hiding in there. Now they’re not going to be very specific in the fact of asking you exactly what’s going on, but using this, you should be able to see certain things, for example, are they trying to do an SQL inject?

If so, they’re probably using that single quote and they’re using an equal sign. If they’re trying to do something like XML, you’ll see XML being passed. If their trying to load a JavaScript, they’re going to do something like what I just showed you here in the URL. These are the kind of things you’ll have to do. Now, what do you do if you don’t remember all those codes because that’s a lot of percent encoding, all those different codes of remembering %3F and %2E, and things like that. Well, on the exam, it’s all multiple choice, right, and so when you get a question, you may not remember what %3C and %3E were, because that was the brackets for the script on the other side.

But you did see the word script and so if you see the word script, you might think, Hey they might be trying to pass an HTML script or a Java script there and as you saw the rest of it, you could read things like ABC123.com, which is a web link and so you’re seeing that you’re going to Dion Training but now you’re sending another web link as part of this URL and that should flag to you that there’s something wrong here. So even if you don’t remember all of the colons, and the back slashes and the dots, you can probably put together most of this based on what you’re reading in that URL, as you’re doing your analysis for the exam. In the real world though, I do recommend having one of these charts handy because then you can read exactly what it is and really put it back together.

35. Cryptographic Flaws (OBJ 2.1)

During our information gathering, we need to determine what kind of encryption the target systems are using. Now, most encryption these days is done using digital certificates and SSL or TLS for encryption. To determine information about the web server’s encryption capabilities, it’s important to conduct cryptographic inspection. This allows us to see if there are valid certificates being used by the the server, or if there are any potential vulnerabilities that we can exploit later on. For example, if you look at the cryptographic information for a given web server, you should be able to determine if they’re using SSL 2, SSL 3, TLS 1.0, 1.1, 1.2, or 1.3. Just by manually looking at the server’s digital certificates, or listing their associated cipher suite. Now, as you look at the server, you may find that they’re using an out-of-date protocol like SSL 2, or SSL 3, which are vulnerable to exploitation. And this is good information to know as you start outlining and planning your future attacks.

Now a cipher suite is going to find the algorithm that’s supported by the client and the server when you’re requesting to use encryption and hashing as part of the communication session for that connection to a server. Now, by looking at the cipher suite, you can instantly see exactly what encryption and hashing algorithms have been negotiated by the client and the server for particular network connection or session. For example, if you’re using TLS version 1.2, you might see the cipher suite displayed as ECDHE_RSA_AES128 _GCM_SHA256. This would indicate that the server is using Elliptic-curve Diffie-Hellman ephemeral mode to negotiate the session key agreement that we’re going to be using RSA for digital signatures and an AES with Galois/Counter Mode with 128 bit block size for symmetric bulk encryption, as well as a SHA256 hashing algorithm to conduct our message authentication. Similarly, if we look at TLS version 1.3 cipher suite, we might see something that looks like TLS_AES_256_GCM_SHA384. This shows us that the TLS 1.3 protocol will use an ephemeral key agreement since it’s the only type of key agreement supported in TLS. 1.3.

And the AES Galois/Counter Mode with a 256 block is going to be used for symmetric bulk encryption and SHA384 is going to be used to support cryptographic hashing functions for us. Now as a penetration tester, it’s really important to understand how to read these cipher suites because you may be looking at a vulnerability scanner report and need to identify which one is most vulnerable because it has an insecure cipher type that’s being used. Now as a cybersecurity professional, we’re going to be looking at these cipher suites and then we’re going to determine which one needs to be removed or allowed to increase security. But as a penetration tester, we’re looking at which ones are vulnerable for us to attack. For example, many servers are going to support a large number of different ciphers inside of their cipher suites because this’ll provide the most services to the most users.

If the user is going to be using an older or less secure web browser, for example, the server can then downgrade its security to an older session. For instance, it might use SSL 2 or SSL 3 instead of using TLS 1.2 or 1.3, to be able to support that older user. Now, while this provides better service for that user, it does lead to a vulnerability because we can do a downgrade attack and be able to force the server to talk to us in something that’s less secure and then we can actually hack that session. For example, let’s take a look at my own web server at diontraining.com. Now we’ve explicitly denied the use of TLS 1.0, 1.1, as well as SSL 2 and SSL 3. Instead, we require all users to connect to us using a browser that supports at least TLS version 1.2. Now, as you can see here, the cipher suites are listed by our server in the order of security and preference. Our server first tries to negotiate for the most secure cipher suite. In this case, Elliptic-curve Diffie-Hellman ephemeral mode to negotiate the session key.

And then we’re going to use RSA with a CHACHA20 for digital signatures, and POLY1305 for symmetric bulk encryption, and finally SHA256 hashing algorithm to be able to do all of our hashing and message authentication. Now, if our server can’t negotiate that, it’s going to move on to the second choice, which is Elliptic-curve Diffie-Hellman ephemeral mode to negotiate the session key agreement, RSA for digital signature, with an AES Galois/Counter Mode with 128 bit block size for symmetric bulk encryption, and a SHA256 hashing algorithm to conduct that message authentication. Now, as it continues down the list, if we’re not able to negotiate for one of our top five choices, which are all considered strong, we might move down to something in the weaker options. And this will switch from AES mode of operation, going from GCM or Galois/Counter Mode, down to CBC which is cipher block chaining. While this is a weaker mode, it’s still considered acceptable on our main website because we’re not taking any personal information or credit card payments on that portion of our website. Now this was a business risk decision that we made based on our particular use case.

And most cipher suites in the TLS version 1.2 protocol are going to be considered strong enough for a public-facing web server like ours as long as you’re not taking credit card payments. If you’re doing credit card payments, you’re going to want to go for higher levels of security. In our case, we use a third-party credit card processor, and they have that higher level of security when we take your payment. Now, if you’re doing a penetration test and you want to test a web server to see its cipher suite, you can simply go to ssllabs.com, enter in the website, and your digital certificates and SSL and TLS configuration will show up just like mine did. Now, additionally, you can also review the digital certificates to determine if they’re out of date and can be a source of vulnerability. Now, up to this point, I’ve mentioned a lot of different encryption algorithms and different modes loads of operation. For example, I mentioned Chacha and RSA and AES and GCM and CBC and all of those things.

For this exam, you are not going to be asked about those particular things, but you should realize that cipher suites are made up inside of these protocols that we’re looking at with SSL and TLS. And as you’re negotiating those protocols, you can downgrade to a lower version as part of an attack to be able to make it vulnerable for you to exploit, and keep that in mind for the exam. Also, you should remember that SSL 2 and SSL 3 are considered insecure these days. You should not be using them. You should be using at least TLS 1.2 or 1.3 in a modern environment. All right, let’s talk a little more about digital certificates. Now, digital certificates are things you can also look at to determine if they’re out of date and they might be a source of vulnerability for your sites as well. For example, if the website’s digital certificate expired last month, it’s going to start giving users a security warning whenever they try to connect to the site. Now those users may be used to clicking, “Okay, I accept.” And this warning is going to be the same one that’s going to appear if you trick them into connecting to your site, using a falsified digital certificate too. So that site, by having that out-of-date certificate on the real site is starting to teach bad behaviors to their own company’s users and you can use that to your advantage.

For example, I’ve come across numerous governmental websites that use a valid digital certificate, but those digital certificates were issued by their own certificate authorities. And because those certificate authorities are not installed by default in most users’ web browsers, those governmental websites, they’re supposed to be very secure, have now trained their users to click, “Okay, I accept the risk” and move on. This makes those organizations much more vulnerable to a technical social enduring attack involving these insecure digital certificates because they’ve now trained their users to effectively ignore the security warnings. Now, when you’re conducting cryptographic inspection during a reconnaissance, you should also look at the different fields in a digital certificate to identify other potential targets or servers. For example, there is a field called the SAN field, S-A-N, and this is used to allow digital certificate to be used with other domain names, in addition to the main domain.

This SAN field, which stands for subject alternative name, is used to list any other domain names that can be used on that certificate. For example, I own diontraining.com and if I also owned diontraining.net or diontraining.org, I could list those as subject alternative names on my digital certificate. Certificates that uses subject alternative name are also referred to as a multi-domain certificate because it can support multiple different domain names with one certificate. Now these certificates do support multiple different domains using that SAN field, but they do not support subdomains. If you need to support subdomains with a single certificate, that administrator is going to have to use a Wildcard digital certificate, something like *.diontraining.com. Now this would allow a single digital certificate to be used both on diontraining.com and members.diontraining.com, too. Wildcard certificates allow all the subdomains to use the same public key certificate and have it appear as valid. Wildcard certificates are easier to manage for the system administrators, especially if all their web servers are going to be subdomains off the main website.

But they do tend to cost a little bit more than a single domain certificate. In fact, for all of my websites, we utilize wildcard certificates because it gives us that ease of maintainability. Essentially, when you get a wildcard certificate, it’s going to state that the certificate is valid for *.diontraining.com or whatever your website is. Now, this means regardless of what subdomain we’re using, it’s still going to be protected using the same digital certificate. Now with every advantage, there are some disadvantages to consider. Now, from the system administration side, the biggest disadvantage for us is that if one of our servers becomes compromised, and we have to revoke that certificate, this is going to affect all of our other subdomains too. Luckily, reissuing a new certificate is a pretty quick process because we only have one wildcard certificate that we have to issue, and we can issue it to all of our servers and get them back online again. Another place you’ll see people use wildcard certificates is when they’re using all of their servers behind a load balancer or a content switch.

This allows them to create to single digital certificate that’s going to serve up for all of the different servers and hosts are behind that load balancer. And that way, they can scale quickly as they go up and down in a cloud-based architecture. Now, as a penetration tester, as you start looking at these digital certificates, you want to look at the SAN field or the wildcard to be able to determine if there’s other domain names or subdomain that you’re going to need to investigate as part of your scope. Now, all of our digital certificates are going to be considered valid for a set period of time. And if one of them gets stolen, such as by an attacker or a penetration tester, then the system administrator has to revoke that certificate. When that certificate is revoked, it’s going to be added to the certificate revocation list, known as the CRL. Or it’ll be invalidated using the online certificate status protocol known as OCSP. The certificate revocation list is simply an online list of digital certificates that the certificate authority has revoked. Usually because they were compromised or suspended.

This certificate revocation list is a full list of every certificate ever revoked at certificate authority. It’s going to be distributed throughout the entire PKI hierarchy to all of the subordinate and intermediate certificate authorities. Whenever a device is trying to validate if it should accept a digital certificate, it’s first going to check the expiration date of that certificate. If the expiration date is already been reached, then the system automatically considers it invalid. If the certificate hasn’t reached this expiration date, then the system should check the certificate revocation list to ensure the certificate is still valid and hasn’t been revoked. Now, the other method of checking a digital certificate is to use OCSP or the online certificate status protocol. This is a protocol that allows us to determine the revocation status of a digital certificate using its unique serial number. Now, this is an alternative to using this certificate revocation list and operates a lot more quickly and a lot more efficiently because we’re just checking one certificate and not all the certificates. Now, instead of having to send and receive the entire CRL each time, the OCSP can just be used to check that single digital certificate using its serial number. The OCSP server is going to be responsible for providing the decision on if that certificate is valid or not. And the server is also known as an OCSP responder. Now with the CRL or OCSP, all the burden of validating that certificate is being placed on the client instead of the server. To overcome this limitation, we can use certificate pinning or certificate stapling or HSTS.

Now, as a penetration tester, you need to be aware of these three techniques because they can be used in different ways during your attacks and exploits for you to gain access to servers and networks they’re protected by digital certificates. First, we have certificate pinning. Certificate pinning is a method of trusting digital certificates that bypasses the certificate authority hierarchy and the chain of trust in order to minimize on-path attacks. Without the use of certificate pinning when establishing a TLS encrypted tunnel, an attacker could attempt to substitute a malicious but trust a certificate into the chain of trust that includes the client, the server, and the intermediate or root certificate authorities by using an on-path attack. Now, once this is done, that attacker or penetration tester could eavesdrop on the supposedly secure communications between that client and the server. Certificate pinning was one of the first methods used to try and mitigate this type of vulnerability.

And so they came up with this idea of HTTP public key pinning, which allows a website to resist impersonation attacks from those presenting fraudulent certificates by presenting a set of trusted public keys to the user’s web browser, as part of the HTTP header. If the web browser didn’t get the matching public key from the certificate authority, then it knows the website was compromised and it alerts the users. Unfortunately, attackers and penetration testers found serious vulnerabilities and ways to exploit the HTTP public key pinning technique. So now it is considered deprecated and not used. Instead, we’ve moved on to certificate stapling instead. Now certificate stapling allow as a web server to perform certificate status checking instead of using the web browser. The web server is going to check the status of the certificate and provide the browser with a digitally signed response from the OCSP responder. This method resolved the issues of certificate pinning by having the web server go out and obtain a timestamped OCSP response from the certificate authority.

The certificate staling then allows a certificate holder to get the OCSP record from the server at regular intervals and then include it as part of the SSL or TLS handshake. By doing this, it eliminates the requirement for an additional connection at the time of the user’s request and speeds up the creation of the secure tunnel. This means the client doesn’t have to make the OCSP requests themself and this speeds up the entire process. Now, there is a newer technique and this is called HTTP strict transport security, also known as HSTS. Now, in HSTS, the web server is configured to notify web browsers that are connecting to it that they should only request the site using HTTPS and not HTTP. This means you have to use an encrypted tunnel and not something that is insecure. The way this works is that when the client attempts to connect to the web server over HTTP, it’s going to receive the webpage header, which has a strict transport security option set. And it’s going to have an expiration date and time. The browser then knows it can only connect to this website using HTTPS instead of HTTP.

And this can prevent on-path attacks by exploiting the HTTP website connection. Now, some web hosting providers will simply use a redirect instead of using HSTS and they’ll redirect from HTTP to HTTPS version of their web server. Now, this is not a secure and it is something you can exploit. If you’re working as a system administrator or a web server administrator, you want to make sure you’re setting up the HSTS setting in the head of your webpages because it is much more secure. Now, in addition to setting up that HSTS on your web pages, you’re also going to find there is a pre-load list that contains a list of sites that should never be accessed using HTTP in most of the modern web browsers. Now, this is a really long list with over a hundred thousand domain names included by default. And as a penetration tester you want to see is one of the sites you’re testing going to be in that list, because if they are, that’s going to cause some problems for you during exploitation if you’re trying to get an on-path attack going. All right, as you can see, there’s a lot of valuable information that can be gained from digital certificates during your cryptographic inspection. And by identifying the type of digital certificate techniques being used, you can then plan different exploitations and attacks in phase three of your engagement.

36. CWE & CVE (OBJ 2.1)

To be effective at information gathering and identifying possible vulnerabilities, a penetration tester needs to keep up-to-date with the latest techniques and vulnerabilities because, as you know, vulnerabilities frequently change. We always need to keep on top of this. Every time there’s a new security breach, we are provided with the opportunity to add a new tool to our penetration testing arsenal. There is a lot of different sources available and it’s not my goal here to provide you with an exhaustive list. Instead, I’m going to try to focus on a few places that you should recognize and, more specifically, a few types of information that are called up by the exam objectives such as CVEs and CWEs. Please realize though, there are many more options available out in the real world including security blogs, podcasts, and others. The website you should know about first is the Computer Emergency Response Team or CERT.

This is located at cia.gov/uscert. This website is maintained by the United States federal government and it lists all the different known vulnerabilities that have been identified in the wild, as well as those that are self-reported by industry partners. For example, we could click on an article titled “CISA Releases Advisory on Destructive Malware Targeting Organizations in Ukraine,” to find out all about the recommendations and strategies to prepare for and respond to destructive malware or, perhaps, CISA will also have added four new vulnerabilities to its known exploited vulnerabilities catalog, and you could review those as well. JPCERT is our next website. JPCERT is Japan’s version of the Computer Emergency Response Team and it contains similar alerts and advisories about what viruses are on the rise according to their internet threat monitoring. Their website is located at jpcert.or.jp and they do have an English version of that as well. Another great resource is known as the NVD or National Vulnerability Database. The National Vulnerability Database is provided by the National Institute of Standards and Technology known as NIST. This US focused site is located at nvd.nist.gov and the webpage displays all the latest vulnerabilities, and assigns each of them a CVE number. For example, there may be a CVE called CVE-2022-123.

This means it’s the 123rd vulnerability that was identified during the calendar year of 2022. Each CVE also has a score associated with how dangerous it is listed as either critical, high, medium, or low severity. Generally, when conducting a penetration test I focus the majority of my efforts on finding and exploiting the critical and high vulnerabilities in my target networks. As you might imagine, there are lots of vulnerabilities and new ones are coming out all the time. But don’t worry, it isn’t necessary to memorize every single vulnerability out there. However, you do need to know where to look because if I identify a target server as running Apache 2.2.2.6, for instance, I can then go and see if there’s any vulnerabilities associated with that particular version of Apache. This can then lead me to an exploit, which can provide me a way to enter into that victim’s network as a penetration tester. Now, you may be wondering what exactly is a CVE, and why does the NIST website use them to reference these different vulnerabilities? Well, the acronym CVE stands for the Common Vulnerabilities and Exposures, and there is a compilation of them located at cve.org.

This common database is used worldwide, and every single vendor submits their known vulnerabilities to the CVE database, Microsoft, VMware, Norton, and all of the others. Anytime there’s an issue found with their hardware or software they submit it into the CVE database, which means this is a great place for us to look when we’re doing our open source intelligence and research efforts. Another great source of information is the Common Weakness Enumeration, or CWE, which is located at cwe.mitre.org. This is a community developed list of all the different types of software weaknesses, and the details for those weaknesses. Now, these aren’t necessarily vulnerabilities, like the ones listed as CVEs, which are more focused on a particular software product and version. Instead, these are common vulnerabilities across all types of software, therefore, as a software coder or somebody who’s conducting penetration testing for software, you should be familiar with and look at the community list as it’s continually being updated and expanded. Another thing you should look at is CAPEC, which is the Common Attack Pattern Enumeration and Classification, which is located at capec.mitre.org. This website exists to help us understand and identify a particular attack, so that security researchers can better understand the different attack patterns.

As of February 2022 there were 546 distinct attack patterns that are used by various threat actors around the globe. This is useful for penetration testers to learn because these are attack patterns that we could be using during a penetration test, or we could be asked to emulate during a red team exercise. For example, if we find a particular threat actor often uses a particular attack pattern, we could then emulate that as part of our red teaming and CAPEC is an incredibly useful tool from that perspective. Another option for us is known as full disclosure, which is a mailing list from the makers of NMAP. As you’re soon going to learn NMAP is a crucial tool for our scanning enumeration and fingerprinting efforts. NMAP’s full disclosure list can be read online, received via email, or pushed to your favorite RSS reader making it a great way to keep up-to-date with the latest cyber security threats and breakthroughs. Now, I know that was a lot of different websites that I just threw out at you. On exam day, you’re not going to get asked about a specific website, but you are expected to understand key terms like CVEs and CWEs, and how they could be used to link a vulnerability to a potential exploit. In fact, when you start using some exploitation framework tools like Metasploit, they actually link their exploits to the CVE numbers to make things even easier for you. When you run a vulnerability scan against the target, which happens in the vulnerabilities scanning part of our engagements, those tools will also report the vulnerabilities in terms of CVEs too most of the time, making it really easy for you to identify, and then link them to an exploit as a penetration tester.

• Category: Uncategorized