Select Monthly Archives
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- March 2014
- January 2014
- December 2013
- September 2012
Filed In: InfoSec, Security Testing, Application Security
Written By: Jayme Hancock May 23, 2017
Over the past week, we’ve seen that a lack of basic security practices can make systems administrators at organizations of all sizes WannaCry. It can be difficult for an IT professional to know what matters and how security should be prioritized, without the luxury of a dedicated security team. Especially vulnerable are smaller IT shops that spend their time fighting fires, keeping services online, and meeting end user needs. In this article, I want to help address that by recommending some easy to implement, but highly effective mitigations that you can put into place right now to help defend your organization against all types of threats. This is not a comprehensive list, but the following recommendations (in no particular order) give a very high return on investment.
Recommendation #1: Simplify Your Patch Management
Many attacks, including WannaCry (and its underlying delivery mechanism), target unpatched systems. Both operating systems and applications should be updated regularly – whether external facing or not.
While this seems like an obvious statement to make, unpatched or end-of-life systems can be found on a staggering number of production networks. End-of-life software and operating systems no longer receive patches against newly discovered vulnerabilities and should be taken out of production as soon as possible.
For Windows shops, Windows Server Update Services (WSUS) is an excellent, no-cost option to centrally administer patches for many Microsoft products. WSUS is easy to set up, and can be configured to automatically or manually push new updates to groups of clients. Third -party software is a bit trickier, but there are commercial plugins that allow for WSUS to patch software from other vendors. For small environments, a third-party update tool like Ninite could be an option – its not automated, nor is it free, but makes third-party application patching centralized and very straightforward. Tools such as Flexera’s Corporate Software Inspector, and Microsoft’s System Center Configuration manager (SCCM) can also help to manage third-party application patching.
Recommendation #2: Audit for Blank and Default Passwords
The 2016 Verizon Data Breach Investigations Report stated that “…63% of confirmed data breaches involved leveraging weak/default/stolen passwords,” so it should come as no surprise that this recommendation is high on the list. Default and blank passwords should never exist in your environment, period. These credentials are meant to be changed on first use, and before the system is put into production – but too often, this goes overlooked. Default passwords are included in wordlists used by attackers to perform attacks, and are trivial to find with a little Google searching. An attacker can leverage default passwords on network devices such as switches and access points to redirect traffic, perform man-in-the-middle attacks, or perform a denial of service attack against the organizations infrastructure. Worse still, internal facing web consoles that use default credentials on applications containing sensitive business data or system configurations are often left untouched because the application is “internal only.” Because attack vectors such as phishing and malware are commonplace and bypass the perimeter, and malicious insiders are a real threat, the “internal only” argument should not be considered valid. Audit all logins to verify that their default passwords have been changed. Many devices and services now have support for two-factor authentication – if this is available, it should be enabled to give you an extra layer of protection.
Figure 3 - Default password lists: Just a Google search away
Recommendation #3: Secure your Local Administrator accounts with LAPS
A common culprit of password reuse is the Local Administrator account on Windows workstations and servers. This password is traditionally set to a common value through Group Policy, or to a standard value when building the system image. As a result, an attacker who discovers the local administrator password on one machine now has access to all machines on the network.
In mid-2015, Microsoft released a tool to address this issue: the Local Administrator Password Solution (LAPS). The LAPS tool sets a unique, rotating, and more importantly, complex value for local administrator accounts and stores the value as a Computer Account attribute in Active Directory. This attribute, “ms-Mcs-AdmPwd,” can be locked down via ACL, to ensure that only approved users (such as helpdesk and systems administrators) can view the password. LAPS also includes a PowerShell module and a thick client, the LAPS UI, to simplify management and retrieval.
LAPS implementation is quick and straightforward, requiring the systems administrator to create a GPO defining the password policy and local account names to manage. A single file, AdmPwd.dll, will need to be added and registered to each Windows machine in your environment (or included in your disk image).
Figure 5 - The Local Administrator Password Solution allows the systems administrator to define passwords that adhere to their corporate policy.
Recommendation #4: Limit Information Disclosure
Finding an overly verbose error message can be a goldmine for an attacker. While these may seem relatively benign at a glance, verbose error messages can leak information to help craft an attack strategy– such as internal IP addresses, local paths to sensitive files, server names, and file shares. From this information, other environmental characteristics can be inferred, and can assist an attacker in gaining a clearer picture of your operating environment. There is rarely ever a reason a user would need to see this information - generic error messages should always be displayed instead.
Simply displaying software versions gives an attacker a place to start researching their attack. For example, disclosing that a server is running Tomcat 8.0.3 reveals to an attacker fifteen published vulnerabilities, some of which have proof of concept exploit code available. Test pages and configuration summaries should be removed or restricted as well – for example, a page displaying phpinfo() could reveal host information, such as the user and group running the service, the server’s configuration options, and other information.
Figure 6 - A page displaying phpinfo() discloses information that could lead to further targeted attacks.
When deploying an application, ask yourself if the information it displays by default is something that needs to be seen by an end-user. If not, remove it.
Recommendation #5 – Disable LLMNR and NetBIOS Name Resolution.
Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are two services that can lead to a quick complete domain compromise when left enabled. These protocols are most often used to look up a requested host when the initial DNS lookup fails – and are enabled by default. On most modern networks, DNS is in place – making these services unnecessary*. When a request is made for a host that can’t be found, (such as a user trying to access \\dc-01 when they meant to type \\dc01), LLMNR and NBT-NS will send a broadcast looking for that host. Readily available tools such as Responder can automatically respond to these requests, and capture the username and password hash of the remote user. The password hashes can then be cracked offline, or passed directly on to other services.
Figure 7- An LLMNR request is poisoned by Responder and user01’s password hash is captured.
Since these services are not usually necessary, the easiest mitigation is to disable them entirely. To disable LLMNR, create or modify a group policy to enable Computer Configuration -> Policies -> Administrative Templates -> Network -> DNS Client -> “Turn off multicast name resolution.”
Figure 8 - Enabling the “Turn off multicast name resolution” Group Policy option disables LLMNR.
Disabling NetBIOS Name Resolution is not as straightforward, and requires that you either disable the “Enable NetBIOS over TCP/IP” option manually in each network adapter, or push out a script that contains the following wmic commands:
- wmic nicconfig where TcpipNetbiosOptions=0 call SetTcpipNetbios 2
- wmic nicconfig where TcpipNetbiosOptions=1 call SetTcpipNetbios 2
*Note: While these services are typically not necessary, some legacy software may still rely on NetBIOS Name Resolution to function properly. Be sure to test how disabling these services will affect your environment before pushing out a GPO.
Recommendation #6: Watch your Account Permissions
A compromised user account is only as useful as its permissions. Users should be given the lowest amount of access needed to do their job. Additional, temporary access should be closely monitored and revoked when it is no longer necessary. There is a tendency for access to accumulate over time, but in my experience, regular removal of these access rights is rare. Access is often granted by technical staff as a quick workaround to end-user issues, but these “temporary” fixes are rarely temporary.
Sensitive accounts (such as those dealing with administrative access) should be separate from the standard accounts employees use to check email and browse the Internet. This helps contain damage should a user account become a victim of a malware or a phishing attack, or in the event of an otherwise compromised password.
Accounts with Domain Administrator and/or Enterprise Administrator group membership should be highly limited and should only be used to log into domain controllers – accounts with these permissions should never log into any other system. Consider creating “workstation admin” and “server admin” groups to assign to accounts with limited administrative functions who don’t need access to the entire domain infrastructure. Get as granular as possible – even if that means creating a number of specialty groups and assigning them individually. This will help with lateral movement and privilege escalation throughout the domain.
Recommendation #7: Know – And Limit – Your Attack Surface
A quick few minutes browsing https://www.shodan.io will make it painfully clear that people expose too many sensitive services to the internet. Does SMB need to be exposed to the general public? What about Remote Desktop Protocol? Is there a requirement for remote users to access these services directly, or can you keep them internal and use a VPN for access? As a general rule, if it doesn’t absolutely need to be on the internet, take it off. Exploits are created every day, and what may seem relatively benign now can change in an instant.
To find what services on your network are available to the internet, try scanning your network ranges with Nmap. A simple scan like “nmap -sV -Pn --top-ports 10000 126.96.36.199/24” can give you quick visibility into what an attacker might see. Tools like Shodan and Censys.io automatically index internet facing websites and give you an easy way to search your network ranges without scanning them yourself.
Figure 9 - Shodan provides a wealth of information on publicly available services and ports.
Do you know all of the services running on your network? For example, are you running IPv6, and more importantly, are you running it on purpose? Is there a business case for SMBv1 to be enabled one very device in your environment? Watch your network traffic and ask yourself why each of these should be allowed to run – if you can’t come up with a reason, disable the service and monitor systems for the impact. Often times, a number of unnecessary services are running by default, and you might not realize this until you find yourself buying Bitcoins to decrypt a computer.
Recommendation #8: Segment Your Network
Flat networks are easy to manage and work out of the box. They also allow an attacker to move laterally throughout your network without restriction – and this is a bad thing.
On a flat network, all users and services can reach all systems and resources. Rarely is there a need for someone on your guest wireless network to access the iDRAC controllers on your SQL server, or a non-administrative user to directly access Oracle. Segment your network into groups that make sense for your organization; at a minimum, I would suggest user, server, out of band management (iDRAC, iLO, etc), and guest segmentation. Use whatever makes the most sense for your environment, but ask yourself the following questions: “What systems and services need to access this resource? Are there other similar resources I should group this with? What is the impact if someone from Segment A can access Segment B?”
Network segmentation allows for extremely granular controls, and should have a default deny in place to drop traffic not explicitly allowed. This makes an attackers job much harder, and can help prevent malware from spreading as easily. In addition to the security benefits, you may notice a boost in overall network performance, as well.
Recommendation #9: Get a Penetration Test
While not a zero-cost mitigation, I feel its necessary to include Penetration Testing in this list. When working with the same systems every day, there is a tendency to overlook potential problems, miss bad practices in production, or subconsciously avoid areas that may present a security issue. Hiring security experts to simulate the actions of a motivated attacker is the best way to determine how you should prioritize security, and how small and seemingly harmless issues can be chained together to do massive amounts of damage. The point of a penetration test is not to point fingers and pass blame, but to identify areas that need improvement. If you are interested in having a penetration test performed, please contact AppSec Consulting today to see how our experts can help!
Implementing these basic security practices will help strengthen your security posture. The truth is, basic security done well – and done consistently - will give a much higher return than any piece of hardware or software you could purchase. As always, test these recommendations before rolling them out, as environments will differ.