187. Secure Coding (OBJ 4.2)
Secure Coding. In this lesson, we are going to talk about some secure coding best practices. And in this lesson, we’re going to talk about input validation, output encoding, and parametrized queries. First, let’s talk about input validation. Now I know I’ve mentioned how important it is when I talked about XML and SQL and directory traverses, and we kept saying input validation was important but we never really defined it. Well, input validation is any technique that you use to ensure the data entered into a field or a variable into an application is handled appropriately by that application. Now, essentially when I take something from a user, I want to make sure it’s actually accurate. If you go to my website and you try to enter in your username or your password, I want to make sure you’re giving me valid data before I send it to my database to try and see if it works. So, when we talk about input validation, this can be conducted in two ways. It can be conducted locally on your client or remotely on the server that you’re trying to access. Now, this means that there’s two different ways to think about this but I want to give you a big warning here. While client-side was used in the past a lot, you really should be careful using it. When you’re using client-side input validation, it is much more dangerous because it’s vulnerable to malware interference.
If I’m testing something on your computer before you send it to my server, I’m now trusting that your computer is doing what I told it to do. And that can’t always be the case because attackers can modify that and malware can modify that. So, you may be wondering, why don’t we just do server-side for everything? Well, server-side input validation can be time and resource intensive because every time I have to check something, that’s processor cycles on the server. And while your computer is only serving you, my server is serving hundreds of thousands of people. And so, that can take up a lot of resources. Now, let me give you a good example of this. Let’s say you went to my website and you’re trying to buy your exam voucher for your exam. You get to the checkout form and it asks for your email, and you type in jason@notmydomain but you didn’t put.com. Notice here, it says this is not a valid email. This isn’t being checked by my server; this is being checked by your client. It knows that the format has to be [email protected], right? It knows that’s what an email looks like. And since you didn’t do that, it’s not going to validate it.
And it won’t let you enter this form. Now, if you just enter.com here, even though that’s not a valid email, it would still accept it because the client-side said that’s good enough. It just needed to be [email protected]. Now input, when you’re validating it from the client, it still needs to undergo a server-side validation after passing the client-side validation. For example, a lot of websites will validate on your client that that looks like it’s in a valid format of email. Then you send it to the server and they’re going to check that it’s an actually a live email address before they process your order. That’s a server-side validation as well, so you can do both. And so, it doesn’t have to be either/or, you can use both. Now, let’s talk about input here for a second. In addition to doing input validation, we also want to do what’s called normalization or sanitization. Now, what is this? Well, normalization is when you take a string and it’s stripped of all the illegal characters or substrings and it’s converted to an accepted character set. For instance, when you go to my website and you enter your name, I expect it to be something that has the alphabet in it. You know, A-B-C-D-E. I don’t expect a bunch of numbers or special characters. And so, if you put in numbers or special characters, the system should do input validation and either reject it or it should normalize it and remove those. That’s the idea of normalization.
Now again, I’ve mentioned in the past the reason why we have to do input validation is because we want to prevent people from doing attacks on us. And some of those attacks are things like directory traversals we mentioned. Well, one of the attacks that people can use against us is known as a canonicalization attack. Now, canonicalization is an attack method where input characters are encoded in such a way to evade vulnerable input validation measures. So, I’ll go back to the example of a directory traversal. I’m going to send something that looks like this: diontraining.com?user=../../../../etc/config diontraining.com?user=../../../../etc/config Now, if I don’t want to fall victim of an attack like this, what can I do? I can normalize that data. I can sanitize it and say, “Oh, any time I see ../ just ignore it. “We’re not going to take it” And we can either reject it or we can just remove that and just pass the etc/config part. Now, if somebody wants to try to send this as their username, we’re not going to process it. Or if we do, we’re not going to fall victim of the attack because we’ve removed those .. slashes.
Now, what happens if they send me this instead? Well, they have diontraining.com?user= %2e%2e%2f, you get the idea, /etc/config. %2e%2e%2f, you get the idea, /etc/config. What is this? Well, they encoded their input to try to get past my validation system, so I need to make sure that I’m aware of this type of attack because I would need to go and sanitize this input, not just for ../ but every variation of ../ that may be used by different encoding mechanisms. So, this is the idea of how you can prevent these canonicalization attacks. Next, we want to talk about output encoding. Output encoding is any coding method that’s used to sanitize the output by converting the untrusted input into a safe form where the input is now displayed as data to the user without executing the code in the browser. So, let me give you a good example of this. Let’s say you took that input from somebody with all those .. slashes and then you outputted it back to the user and said, error, username incorrect. Username cannot be ../../../. Well, what are you doing there? You’re having the ability that somebody you can actually put code into your webpage because if I went and put something like (script) as my username, and then you aired that out and gave it back to me and said, (script alert XXS), (script) is not a valid username. What did you just do?
You put the script into your website and displayed it back to me. Output encoding prevents that. So, for example, instead of taking an &, you would convert that to & If you take a <, you would make that into < If you take a <, you would make that into < Why? Because the < symbol is one of the things we use to make the word script inside our brackets. < script >. So, if we change that to < script > So, if we change that to < script > that won’t execute when you display it back to the user. That’s the idea of output encoding. Output encoding is used to mitigate against the code injection and cross-site scripting attacks that attempt to use input to run that script. That’s what we’re trying to prevent here. Now, the third area we want to talk about is parameterized queries and this is a great technique that is used to defend against SQL injections and insecure object references by incorporating placeholders into an SQL query. Now, what does this look like? Well, when we take these parameterized queries, we’re really doing a form of output encoding. So, let me show you a small program that I wrote. It’s just five lines long, and this is a Java program. Now, I don’t expect you to be able to write this code yourself but you should be able to read it because Java is considered a high level language and it reads fairly much like English. So, let’s take this one line at a time.
Now, string custname = request.getParameter(“customerName”); Now, string custname = request.getParameter(“customerName”); String query = “SELECT account_balance FROM user_data WHERE user_name = ? “; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( ). ResultSet results = pstmt.executeQuery( ). What is this saying? Well, in the first line, this takes the string customer name and requests you to get the parameter customer name, so we’re getting input from our user. The second line, this is the query we’re defining. We’re defining that the query will always be in this format. Select account balance from user data where username equals question mark. The question mark is essentially what we’re going to fill in. Then we’re going to use this prepared statement call, which is going to make a connection to the database using the query. Then, we’re going to make that string get set inside the query using the first position, that first question mark we found, the only question mark, as customer name, and then we’re going to get the results from executing that query. That’s all this is saying. So when we’re using a parameterized query, we’re only going to use this format when sending it to the database. This way, we have different parameterized queries for different functions, like writing to the database, reading from the database, updating from the database for certain fields. And we would use those queries that have already been defined by the programmers instead of trying to create them on the fly using customer data.
That’s what we’re doing here. And this is the idea of a prepared statement. Now, this is not a fully functional program. What am I missing here that can really cause me problems? We talked about it at the beginning of this lesson. That’s right, input validation. Nothing here is validating that input. So when I’m getting the input from the customer, I didn’t go through input validation. So, when I get that input, I should run it through validation before I put it into my query and into my prepared statement but this was an idea of showing you what a parameterized query looks like with these prepared statements. And that’s what I wanted to focus on in this particular code snippet. Now, for the exam, you do need to be able to identify input validation, output encoding and parameterized queries in a given scenario. Remember, anytime you take input from a user, you want to do input validation. Anytime you’re outputting data that came from a user back to the screen, you want to use output encoding. Anytime you want to connect to an SQL database, you should really be using parametrized queries because this is a best practice. It’ll make sure you’re taking the minimum amount of information from a user and putting it into specific fields only inside that database by using those parametrized queries.
188. Implementing MFA (OBJ 4.2)
In this lesson, we’re going to talk about single sign-on, implementing multifactor authentication and encrypting passwords. First, let’s start with SSO. This is Single Sign-On. Single Sign-On is an authentication technology that enables a user to authenticate once and then receive authorizations for multiple services. Now there’s both advantages and disadvantages to using something like single sign-on. When you use single sign-on, the user doesn’t have to have multiple usernames and passwords. This is a good thing. One password to rule them all. It’s one nice, hard, challenging password that you can memorize and then use to get onto everything, because you log on once and have access to all the systems. That’s a great advantage. But the disadvantage is you only have one password. So if your user account is compromised, that attacker now as access to everything. For example, I talked about before, you can use something like LastPass, which is a password manager.
Now this isn’t necessarily single sign-on, but it’s the same concept. If your master password is compromised, they now have access to all of your sites. Well, with single sign-on, it’s essentially the same thing, because you log in once and get access to all of the sites. And so if that one password gets compromised, they get everything. So this is a bad thing about single sign-on. Now, when you’re using single sign-on, for instance, on a Windows domain, you log on to your Windows domain, you have access to all the files and email and everything else, that is single sign on. That’s using Kerberos as a single sign-on tool. Now the next one we’re going to talk about is MFA, which is Multifactor Authentication. This is the buzzword these days. Everybody needs to have MFA. This is an authentication scheme that requires the user to present at least two different factors of credentials. This can come from something you know, such as a username and password, something our have, like a token or a fob, something you are, like a fingerprint or an eyeball scan, something you do, such as the way you sign your name, or somewhere you are, such as your location and your GPS coordinates.
If you have at least two of these five categories, you have multifactor authentication. Now another buzzword you’ll hear is 2FA, and that’s for two-factor authentication. This is when only two of those factors are used, and that’s the most common form of multifactor authentication, ’cause most systems aren’t going to require you to have three or four or five factors, just two. Now, what makes multifactor authentication better than just using the username and password? Well, it’s because you have two factors of authentication. And you can even secure this even further by using things like two-step verification, biometrics, certificate-based authentication, or location-based authentication. Let’s talk a little bit about each of these. Two-step authentication is when you go to log into a website and then, once you put in your username and password, it sends a text message to your phone or an email to you, and then you have to get that code and enter it into the website. This now gives you two factors, something you know, your username and password, and something you have, your cellphone receiving that text message. That’s the idea of a two-step verification.
Now this is a really good way of doing things. And one of the reasons it’s very widely implemented is because almost everybody now has a cellphone. And so you don’t have to have special hardware, you just have to have any smartphone, and you can then get this two-factor authentication. Now, another way you can use multifactor authentication is by using biometrics, and most of our smartphones use biometrics now. You have a fingerprint scanner or a Face ID, like on my iPhone. This is the idea of using biometrics as a login mechanism. Now is Face ID multifactor authentication. No, because when you pull up that phone and use your face, you’re only using your face. Yes, it’s more secure than using a password, but it’s not requiring two factors, it’s only requiring your face. So this would not be multifactor by itself. But if I had to put in a PIN and my face or a password and my face, that would then be multifactor authentication. Another factor you can use is certificate-based.
And this is often done using digital certificates. For instance, on my iPhone, I have same digital certificates installed that identify my as the person holding that phone. So when I go to certain websites, it uses that digital certificate to log me in. Between that and my username and password, I now have multifactor authentication. In my case, it’s a digital certificate and a PIN number, and that will let me get into the website I need to get into. And the final one is location based. This can be done based on your IP address location, although that’s easily spoofed through VPNs or your actual GPS coordinates, which is a much better way of doing it. This, again, is another factor you can use as part of your multifactor. But if you’re just using log in by itself based on your GPS location, that is a single factor. So, for example, if I wanted to log in to my corporate file share, I can pull up my iPhone, it can detect where I am in the world based on my GPS, and if I’m within the United States and I have the right username and password, it would let me login.
That could be a form of multifactor authentication, because in my authentication scheme, you must be in the United States and you must have the username and password. That’s a pretty generic range of locations, but you could make it even more specific and say you must be in the city or within this 50 feet. You must be within our office building or something like that. But again, location based can be done as a way to identify fraud and figure out if your employees really are where they say they are. If I have an employee who’s trying to log in from Russia or China, and they’re sitting in the office, well, that’s obviously fraud and we can then go ahead and turn that account off and figure out how that account has been compromised and get it fixed. So this again is one of those additional factors you can use. Usually it won’t be your primary factor, but it could be a factor that you use as a third degree to make sure the person has their username and password and has their security token and they’re actually in the state you think they should be in when they’re logging in to that service. And that’s why it’s a good third or fourth factor that you might want to use.
But, in general, you’re going to use mostly two-factor authentication or a biometrics in addition with the username and password to be able to create good multifactor authentication. Unfortunately, though, not all solutions will support multifactor authentication. If the service or application you’re using doesn’t support multifactor authentication, then you’re going to need to use long, strong, and complex passwords. In this case, you should store those passwords in an encrypted format in a password manager, because this will allow you to have long, strong, unique passwords for all you’re different sites, services, and applications and not forget any of the credentials. The important thing here though is that you are encrypting those passwords when you’re storing them and use a good database solution like Bitwarden, LastPass, OnePass, or others to be able to store all those passwords instead of just typing them all out in a Word document or an Excel spreadsheet and saved on your desktop, because that is a huge vulnerability.
189. Digital Certificates (OBJ 4.2)
In this lesson, we’re going to talk about digital certificates and how you can use them as part of your remediations. We’ll talk about certificate management, certificate pinning, certificate stapling, and HTTP strict transport security. To ensure a secure PKI system, you need to maintain proper life cycle management for the certificates and the key pairs being utilized. This includes managing the entire life cycle of your certificates from their generation to revocation. There are eight phases in the certificate life cycle, generate, provision, discover, inventory, monitor, protect, renew, and revoke. First, we have generate. In the generate step, our organizations can be focused on our policies and processes that allow a certificate to be requested and issued to a client or device. Second, we have provision. In the provision step, our organization’s going to issue the certificate. Our policies concerning the provision step should be focused on describing the different types of certificates that we can issue and the conditions under which those certificates will be issued to a client or device.
Third, we have discover. In the discover step, our organization is going to focus its efforts on incorporating modern capabilities into the environment to scan and identify the certificates in use. Fourth, we have inventory. In the inventory step, our organization will formally document every certificate in use, including information about those certificates. This includes the purpose of the certificate, the certificate chain information, the issuance date, and the expiration date for a given certificate. Fifth, we have monitor. In the monitor step, our organization will use mechanisms to identify any changes to the certificates or any suspicious activity related to a certificate’s usage. As we monitor our networks, we’re not just monitoring our certificates though, but we’re also looking for any unknown or self-signed certificates that are being used in our environment. This could be an indication of unauthorized or malicious activity. Sixth, we have protect. In the protect step, our organization is focused on the protection of our private keys through the use of technical controls, like using key encrypting keys and bit splitting techniques. Seventh, we have renew. In the renew step, our organization needs to identify any certificates that have a pending expiration date so they can be replaced with a new key. This will renew our digital certificates by replacing them with newer, more updated versions. To the maximum extent possible, you should always incorporate automation into the certificate renewal process, instead of relying on manual intervention.
Eighth, we have revoke. In the revoke step, our organization is going to implement processes to identify the need for revocation of a digital certificate and follow those procedures when needed. It’s also important that we understand the scope of revoking a digital certificate based on a specific use case, and work to renew or replace a certificate with a new one if that device’s functionality needs to be maintained. Additionally, during the revocation process, the certificate will get added to the certificate revocation list promptly to ensure the certificate is no longer considered valid for use by other systems. Now when a digital certificate is issued in the PKI system, it has a listed expiration date within that certificate, much like when you get your driver’s license and it’s valid for a certain number of years, and once you reach that expiration date, your license is automatically revoked. But what happens to your license if you get too may speeding tickets? Well, your license can be suspended or revoked, but the physical license in your wallet would still show that you have a valid date of 2025 or whatever your expiration date was. To solve this issue with your driver’s license, police will check your license against the central database whenever they pull you over for a speeding ticket next time. This database doesn’t look at your license based on the expiration date, but instead, it looks to see if you’ve been placed on a revocation list, and if you were, the police might arrest you and tow your car because you’re driving without a valid license.
Well, digital certificates work much the same way, in that they will automatically expire on a certain date, but they can also be revoked any time before that expiration date by the certificate authority for a number of different reasons. For example, if you worked for my company and we issue your digital certificate, and you just quit to take a new job somewhere else, we’re going to revoke your digital certificates because you’re not employed here anymore and don’t need to have access to our systems. Similarly, if your digital certificate was compromised somehow, we could revoke your digital certificate and issue you a new one. In general, we categorize the reasons for revocation as cessation of operation, a CA compromise, a key compromise, superseded, or unspecified. A digital certificate can also be suspended instead of fully revoked, if you need to. For example, at one of my previous organizations, we issued smart cards to each employee that had their digital certificates embedded into the card. If an employee claimed they lost their card, but think it might be lost in one of the drawers of their house, well, we could suspend their card for 72 hours to give them time to find it. When we suspended the card, it also suspended their certificates. If they couldn’t find it within 72 hours, we would then revoke their certificates and issue them new certificates and a new card. If they did find the card, we would simply reinstate their certificates, and they could continue working as normal. The big difference between a suspension and a revocation is that a suspension can be reinstated but a revocation cannot. To manage all these revocations and the status of certificates, each certificate authority uses a CRL, or certificate revocation list.
The certificate revocation list is an online list of digital certificates that the certificate authority has revoked because maybe they were compromised or they went ahead and suspended some kind of a certificate. This certificate revocation list is a full list of every certificate ever revoked by that certificate authority, as distributed throughout the hierarchy to all the subordinate and intermediate certificate authorities as well. Whenever your 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 it’s expired, well, that means we’re going to automatically consider it invalid. If the certificate hasn’t reached its expiration date, then the system should check the certificate revocation list to ensure the certificate is still valid. The second method of checking a digital certificate is to use something known as the online certificate status protocol, or OCSP. Online certificate status protocol is a protocol that allows us to determine the revocation status of a given digital certificate using its serial number. This is an alternative to the certificate revocation list. It operates much more quickly and efficiently, ’cause we don’t have to download the entire list. We can just look for this one particular certificate.
The OCSP server is responsible for providing that decision on if the certificate is considered valid or not valid, and this server is called the OCSP Responder. So, when checking a certificate, you have two main ways to do it. One is to check the full CRL, and the second is to look at an individual certificate using OCSP. Now that we’ve covered the basics of certificate management and certificate revocation, let’s take a look at some additional web traffic security precautions that you can do by implementing PKI in your networks. This includes certificate pinning, certificate stapling, and the HTTP strict transport security, or HSTS as it’s also known. First, let’s talk about certificate pinning. Certificate pinning is a method of trusting digital certificates that bypasses a certificate authority hierarchy and chain of trust. This allows us to minimize on-path attacks. Now without the use of certificate pinning when establishing an SSL or TLS encrypted transport connection, an attacker could attempt to substitute a malicious but trusted certificate into the chain of trust that includes the client, the server, and the intermediate and root certificate authorities, by using an on-path attack. Once this is done, the attacker could eavesdrop on the supposedly secure communications between that client and server. Certificate pinning was the first method to try to mitigate this vulnerability. HTTP public key pinning 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 doesn’t get the matching public key from the certificate authority, then it knows that website was compromised and it alerts the user. Unfortunately, attackers found serious vulnerabilities to exploit within this HTTP public key pinning technique, so it is now depreciating. Instead, we can utilize certificate stapling. Certificate stapling allows a web server to perform certificate status checking instead of that browser doing it. The web server checks the status of a certificate and provides the browser with a digitally signed response from the OCSP responder. This method resolves the issues of certificate pinning by having the web server obtain a timestamped OCSP response from the certificate authority.
Certificate stapling 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 the user makes the request, and speeds up the secure tunnel creation process. This means the client doesn’t have to make the OCSP request themselves, and instead, they allow the server to do it on their behalf every so often in getting that request to them. This will actually speed up the entire process. Now another technique that helps us secure our web traffic is known as HTTP strict transport security or HSTS. In the HSTS, the web server is going to be configured to notify web browsers that are connecting to it that they should only request this website using HTTPS and not HTTP. The way it works is that when a client attempts to connect to the web server over the insecure HTTP protocol, it receives a webpage header called a strict transport security with the option that says an expiration date and a time.
Now the browser then knows it can only connect to this web server using HTTPS and not HTTP, so it will go back and do it that way. This can help prevent on-path attacks that could exploit the HTTP insecure web connection. Alternatively, you may see that some web hosting providers will instead use a redirect from HTTP to HTTPS using a 301 redirect. This is not considered as secure as using the HTTP strict transport security setting in the header of your webpages though. In addition to setting the HSTS on your own web servers, you’ll also find there is a preload list that contains a list of sites that should never be accessed using HTTP in most modern web browsers. Now this is a really long list with over 100,000 domain names that are included by default inside of the one for Firefox as an example.
190. Other technical Controls (OBJ 4.2)
In this lesson, we’re going to discuss other technical controls, these include key rotation, secret management solutions, process-level remediation, and network segmentation. First, we have key rotation. Key rotation is the process of periodically generating and implementing new access keys to a server or service. Basically, think about this like changing your password, but we’re doing this with a key, that key can be either a password, a digital certificate, or other things that are used as a shared secret. It is considered a best practice to rotate your keys frequently, such as every 30 days or every 90 days, depending on the confidentiality of the data you’re trying to protect. Second, we have secret management solutions. Now, a secret management solution is any platform that’s used to control passwords, key pairs, and other sensitive information that needs to be stored securely.
Essentially, think about this as a database for all of your passwords and API keys. These solutions normally take the form of a password manager or other technical database solutions that use encryption by default. When you’re using a secret solution, make sure that it’s one that is secure and from a vendor you trust. Third, we have process-level remediation. Process-level remediation is focused on resolving your findings by changing how a certain process or protocol is being used or implemented. For example, if you found a vulnerability such as they were using Telnet inside their system, you can make the recommendation that they migrate all Telnet services over to the more secure version of SSH instead, or if somebody is using something like HTTP for an internal website, you might want to have them start using digital certificates and running that as an HTTPS server, and that way, it is more secure and the data is being encrypted, this is the idea of process level remediation where you start taking a single process or protocol and then move it into a more secure version of it.
The fourth thing to discuss is network segmentation. Oftentimes, you’re going to find things that are vulnerable in a network, and there is no solid remediation for it. For example, if you’re using Internet of Things devices or ICS and SCADA devices, the best answer for this is going to be to put them in their own network segment. By using network segmentation, you can now divide the system infrastructure into different physical or virtual subdivisions, and this gives you additional choke points where you can place ACLs and firewalls to be able to check data going in or out of those particular subnetworks. Some best practices for using network segmentation include putting all of your printers on a single subnet or putting all of your Voice over IP devices inside their own VON as well. By segmenting out different device types that may have lower security protections, you can increase the security of your overall network.
191. Mitigation Strategies (OBJ 4.2)
In this lesson, I want to provide a quick recap or summary of some of the major findings that you may have during your engagements and some basic recommendations to solve those issues. I like to call this combination of the findings and remediations as mitigation strategies. These will usually be added into your finding section and remediation sections of your final report. But some of the more important ones may also end up in your executive summary or conclusion sections too. Remember, when you provide your findings and recommendations, you should also prioritize them based on the threat, the risk rating, and the cost of implementing those recommendations to help the target organization better understand your remediation recommendations. Most remediation recommendations can be categorized into one of three main areas: technology, processes, or people. The first is technology. Technology would be something like adding a new firewall, a new router, a new server, or upgrading a piece of software. We may recommend that they buy a new piece of software or that they use multifactor authentication systems for all of their authentication needs.
Since we’re going to buy any of these things off the shelf, we’re basically going to call these technology solutions. The second one is processes. Now processes, on the other hand, are things that the organization needs to do to prevent vulnerabilities.
This could be updating their vulnerability management system. Or it might be that they’re afraid of an insider threat, so we’re going to recommend proper employee off-boarding when they get rid of an employee to help minimize that threat because the employee accounts are staying dormant for too long, and we use one of those to break into the system during our engagement. The idea of mitigating things through processes is to figure out exactly how you can fix things by changing the way the organization is operating. Maybe they need to implement mandatory vacation or job rotation, or maybe they need both employees to log in anytime they’re trying to access a secure environment because their physical security was lacking during your engagement.
Whatever the process is, we’re going to give them recommendations on those because there isn’t always going to be a technology solution to every problem. The third one we have is people. This is what I like to call people solutions. Maybe we can recommend better cybersecurity training for the employees because we were able to spearfish them and gain access to their network. Another possible recommendation is for them to hire certified and qualified IT professionals, especially if they haven’t been hiring people of the best caliber previously, and we found ways into their systems because they’re configurations were all messed up.
If they have a lot of security holes and they don’t even know how to properly configure the most basic things, well, that might be a people issue.
Maybe they have a bunch of administrators who aren’t Microsoft certified, or they’re running on the AWS cloud, and they have no AWS certified people. And so maybe instead of hiring people who actually know how to operate the cloud, they’re hiring people who have a regular server infrastructure background, and they don’t understand the differences that happen inside a cloud environment. This can become a big issue for them. So we might recommend better training for their administrators, or we might recommend that they actually need more people, depending on the problems. For example, I’ve been in organizations where they had 10,000 endpoints, but they’re only being supported by about 10 people in the help desk. Now that is not enough people for that kind of workload. They’re going to start taking shortcuts, and that’s going to lead to vulnerabilities. So this became a people problem. Next, we also need to present our findings.
And let’s say, for instance, that we found a shared local admin credentials being used by all the administrators. We can fix this by randomizing credentials and giving every desktop a different password. Next, we need to present our findings, and then we’re going to tell them what we think the solution is. For example, we may have found that there was the same shared local admin password being used for the local administrator account on every desktop in the organization. Now, we can fix this by randomizing the credentials and giving every single desktop its own password. The problem with this, though, is it now becomes difficult for us to manage all these passwords.
So Microsoft has implemented a solution called LAPS, L-A-P-S, the Local Administrator Password Solution. This program is going to manage the passwords for every workstation in the domain, even when you’re logging in without domain credentials. So when we log in as a domain admin, we can do certain things, but there’s other things that we can only do as a local admin. And that’s where LAPS comes into play. LAPS is going to let us do this. It’ll manage all those local admin passwords for us without having to have the same password on every machine across the domain. And this effectively eliminates that vulnerability. This is a great free tool from Microsoft that we can download and implement inside of our Windows domains. Now, what if we found weak password complexity was being used? How can we fix that? Well, we could recommend they change their password policy and recommend creating a minimum password requirement of a certain length and complexity.
For instance, we can say that all Windows domain passwords must be at least 14 characters long, have uppercase and lowercase letters, and must contain numbers and special characters, and they can’t repeat characters or digits. Now once we create that policy, we then have to implement that as a technical solution inside of the domain controller as well. So this is both a process change because there’s a policy involved as well as a technology change because we’re going to have to do that logical implementation. Another finding you might come across is if they’re using plain text passwords. Now, of course, the simple remediation for this is that all passwords have to be stored in a hashed or encrypted format. We should never be storing passwords as plain text inside of our databases. If we find that in one of the web applications for example, we need to recommend that they now use hashes or encryption instead.
Another finding that we may discover is that there’s no multifactor authentication in use. If they’re only using usernames and passwords, we can recommend they add another factor from at least two of the other categories: something you know, something you have, something you are, or something you do. For instance, a username and a password alongside a thumbprint is going to count as something you know. A username and password and something you are, that thumbprint. Or we could use an RSA token instead of a thumbprint, and that’s something you have. By combining these things, we can make policy and technology changes that give more security to the network and prevent other people from using somebody else’s credentials. We might also find SQL injections as one of our findings. If we do, the two main remediations for this are to sanitize user input and to parameterize the queries. When we sanitize the user input, we’re going to check that user data for expected input types. For example, if we’re inputting a phone number into a phone, we should expect it to be numbers and not letters or special characters. Whereas if I’m inputting somebody’s name, I should expect that to only have letters and no numbers in it.
We always want to make sure that we’re getting the data we expect from the user because you can’t trust the user to give you the right thing. Also, anytime you’re trying to take data from a user, you want to make sure you’re clearing that data and sanitizing it to ensure any special characters are escaped out if the user provides them. In addition to this, you always want to use parameterized queries whenever you can because using these prepared statements to query the database means we have bounded variables that are going to be accessing it, and this will prevent a lot of injection attempts. The final thing I want to talk about with findings is when you find unnecessarily open services. Now, if you find something like a server that’s running 20 different services and they only really need to have a web server and MySQL running, in that case, you want to go through that system and start using all of your system hardening practices.
You want to start turning off any ports that are open and shutting down any excess service damans that don’t need to be used. This will help you secure the computer or server and reduce its attack surface. Remember, anytime something is not being used, disable those things. Anything that is unnecessary in terms of services or programs should be disabled or uninstalled. Any ports that are open that you’re not using should be closed down. This is the basic rule of thumb when you’re hardening a system. Anything that you don’t need, go ahead and clear it out because every open port or every additional piece of software is just another vulnerability that attacker can exploit.
