Security+ Topic - Penetration Testing Authorization

At some point in an IT administrators career they do a little dabbling in penetration testing of systems that they have access to. Sometimes these tests start as a simple check of vulnerabilities on their own system and sometimes it ends up being a test against the companies production servers simply because they are curious. What most of these casual or introductory penetration testers do not take into account, is that some of those test could cause a server to stop responding. If the administrator is working against a lab environment or a couple of servers that are not in production, this is usually not a big deal. A simple reboot and then things are back up and running. Things get a bit messier when that same thing happens against the production environment. The owners of a company do not usually take kindly to when their production servers go offline. Let's talk about using a test lab for a moment. Generally speaking a company will have enough resources for an IT administrator to setup a test lab. Some will have a fully virtualized environment that the administrator can simply spin up a few virtual machines into a separate VLAN to do their testing. On the other end of the spectrum is a tight budget IT department with scrutinized purchases. No matter where you are on the spectrum, there is still room for making sure that your penetration testing is not initially on production systems. The reason for these environments is pre-planning in regards to getting authorization for penetration testing on production systems. If you were to go to your management with an idea of penetration testing your production environment and they asked you what the impact would be, the only realistic answer would be that you do not know. Management wouldn’t take too kindly to not knowing if their servers were to go down and because you were the one to take them offline, you are the one getting fired. Doing testing within a lab environment gives you the pushing power for completing tests in a production environment. Company implementations of their server setup are unique and the tests in your lab environment must match that environment as close as possible. After the tests have been completed in the lab environment with proof of what may or may not happen, then you can go to management with a plan for the production environment. Sometimes you may find that a certain vulnerability test identifies an issue in the lab environment and a simple patch corrects the issue. After applying the patch in the lab and verifying functionality, it can then be pushed to the production environment. Once this is completed a plan can be presented to management for a specific vulnerability test in which you confirm the patch is in place and you would like to confirm that the correction is working properly. A lot of what this boils down to is making sure you have permission. Without permission, when something goes wrong it is you who takes the brunt of management. With an outlined plan for what you would like to do and how it is going to be implemented, management can sign off on the process which frees you from repercussions if something happens. Making sure to have all your documentation in place and a plan for what is happening is key to correct authorization.

Security+ Topic - Dictionary Cryptographic Attack

How effective is a Dictionary Cryptographic Attack?  Seriously, how many people really use the word password as their password?  Well according to Wikipedia, password was in the number four spot for 2019 and in the number two spot for the previous 6 years!  That is really amazing and goes to show just how effective a dictionary attack can be even though IT administrators have been enforcing strong passwords for a very long time.  It really is no wonder so many accounts get compromised just based off a dictionary attack.

If we stick with only alpha-numeric passwords from 2019 on the Wikipedia list, these simple passwords are crazy easy to defeat.  password, iloveyou, admin, lovely, welcome, princess, and dragon top their list.  If these are the top of the list then we can only imagine what other words are commonly used but are not used quite enough to make the list.  Granted there are other mitigation techniques to this type of attack such as a limit on the number of attempts, source of login restriction, or up-to-day blacklists to name a few.  This still doesn’t excuse the use of extremely weak passwords based on the dictionary.

I’ve posted in the past about tools you could use which have dictionaries built in and are able to speed through them in their attempts to log into the account.  On top of that, rainbow tables already include most (if not all) of the dictionary and can match a simple dictionary password extremely fast.  In reality we have to take into considerations the default password on customer devices such as DSL Modems, Cable Modems, SoHo Routers, and switches to name a few.  These are most likely the biggest culprit of these easy dictionary passwords.  Still when you weed out those from the list, there are plenty of other simple dictionary passwords that are in use.

What is really boils down to is the fight in regards to “ease of use” vs “secure environment”.  Why do people use simple dictionary passwords?  They are simple to use.  I’ve seen a meme that says “I changed all my passwords to incorrect so whenever I forget it will tell me  that my password is incorrect”.  There is always some truth in every joke and this joke really has application to why a dictionary attack works.  Just last week I went to log into a bank and couldn’t remember my password.  I tried to reset it but it told me that I couldn’t re-use a password that I previously used.  What happened is that I was forced to change my password so many times that I didn’t even know my own password and was forced to use a password I never remember.  Hence the introduction of simple passwords brought from frustration.

End users will almost always use the most simple password that they can come up with.  If their favorite childhood book is “The Cow Jumped Over the Moon” and they have a fond memory of it, their password is now “thecowjumpedoverthemoon”.  The point that I would like taken away from this is to make sure and use a secure password that will be much less vulnerable to a dictionary attack while still maintaining ease of use.  Enforce a password policy that lets the user have a password they can remember such as “thec0wjump$dOVERthem00n” without making your organization vulnerable to a dictionary attack. Aka, not that password.

Security+ Topic - Always On VPN

Having remote access to a corporate or private network is a very powerful tool in the security toolbox. While the setup of a VPN server and client software can take some time, the time-cost benefit is ease of mind when doing work remotely. In the IT industry we know to make sure and connect to secure WiFi and not perform sensitive work on untrusted networks. This is not always the case for remote employees who just want to get the job done quickly and without hassle. This is where some advantages of an Always On VPN setup come into play.

The next question to address for this is what is Microsoft Always On VPN? Historically Microsoft had the DirectAccess remote access process and the Always On VPN is a recreation and improvement on that secure access process. As the name implies, this technology is always running in the background and does not require the user to manually connect. One exception to the rule is if the user is required to enter two-factor authentication as part of the VPN access. When the user is connected via the Always On VPN solution, it is just like they are at their company workplace and able to work on their data or applications as if they were on-site.

When looking at the required items for getting this up and running, it looks similar to the historic DirectAccess setup. As part of evolution of products though, there are many more benefits that the Always On VPN provides such as traffic filtering, granular restriction of network resources via administration controls, working with non-domain workstations and servers, as well as integration with Azure Active Directory. Even further into the benefits is something that most IT administrators will already be familiar with such as where the user is connecting from, the health of the end device, and credential authorizations.

There are a few nuts and bolts to take into consideration of implementing the Always On VPN solution. The process it not yet turn-key but hopefully we will get closer to that goal in the future. The upside of implementing Always On VPN is that most of the underlying components for setup are already in most company setups. The connected components are as follows:

Domain Controllers
DNS Servers
Network Policy Server (NPS)
Certificate Authority Server (CA)
Routing and Remote Access Server

Part of the implementation is that Always On VPN uses Mobile Device Management which provides for flexibility including System Center Configuration Manager, Intune, and other third party platforms. These combined with the multi-factor authentication make for a strong processes in either granting access or denying access.

To further mitigate risk and help control the access, Azure is able to detects sign-in risks based on the behavior of the sign-in request and potentially even blocking a user if warranted. If the location of connection is deemed less secure, there may be a need to prove identity prior to finalizing connection. There is also the ability to restrict access to only corporate-owned and managed devices.

Using Microsoft Always On VPN makes securing the end user and more as seamless as possible. While there is a bit of setup to take on, the benefits are huge. Bringing in a swath of options such as non-enterprise licenses end devices and non-domain joined nodes, Always On VPN is a great option for VPN implementation.