For those of you who aren’t in the loop, BackTrack is a Live Linux distribution that ships with a large number of open source tools that can be used to assess the security of networks, systems, and applications. At this point, most IT professionals and 14 year old computer geeks are at least generally familiar with it. Despite BackTrack’s popularity, I find that very few people are aware that it actually comes with quite a few Windows tools. Most of them are pretty handy and can be easily executed using Wine.
Tools have been included for password cracking, tunneling, remote management and a number of other tasks. Some of the tools that you may already be familiar with include fgdump.exe, psexec.exe, plink.exe, and hijetter. It’s nice to have a few common tools out of the box, but for more ambitious users I definitely recommend installing your favorite Windows tools if they aren’t included.
Below is a quick example of how the Windows tool fgdump.exe can be executed with Wine in BackTrack4:
wine /pentest/windows-binaries/passwd-attack/fgdump.exe -h 192.168.1.101 -u user -p password
If for some reason you don’t already have a copy of Backtrack, go to www.backtrack-linux.or and download it. The creators of the distribution have made an ISO and VMware image available on their site that can be downloaded via FTP or torrent. And it is FREE so you have no excuse.
In the wonderful world of Windows, service accounts are basically the man behind the curtain. Almost invisible to the naked eye, they can be used to run almost any application you can dream up. That includes everything from database services to anti-virus agents. Unfortunately, many companies have a “set it and forget it” attitude when it comes to configuring service accounts. As a result, the accounts are often configured with excessive privileges and then left unmonitored. This has helped create an ideal attack vector for worms, viruses, and, of course, penetration testers.
Below I’ve provided an overview of how service accounts are commonly used and abused, along with a few tricks that can help prevent them from being used to cause havoc in your environment.
What are Windows service accounts?
A service account is a basically normal user account that has been configured with the specific task of running an application. However, these accounts are only used when the application starts and generally aren’t used to log into systems interactively. Additionally, service accounts usually don’t run applications in the foreground like MS Word or Firefox. Generally speaking, there are five types of service accounts.
LocalSystem
In short, LocalSystem is a predefined service account that has more power than Zeus, and basically runs the Windows operating system. Not even the almighty local administrator account can compare. If you don’t believe me, open the Windows Task Manager and navigate to the Processes tab to see what account is running the show. Even today it’s common to see the LocalSystem being used to run application services that require a lot of access to the operating system. It should go without saying, but using the LocalSystem account to run application services it is not considered a secure option and should be avoided whenever possible.
LocalService
LocalService is another native service account that you might see running processes in the Windows Task Manager. It was added when Windows XP and Windows Server 2003 were released in an attempt to provide a secure alternative to running services with the LocalSystem account. The LocalService account has the same privileges as the members of the local Users group, but has very limited access to network resources. It connects to network resources as a null session without credentials. As a result, it is typically used by local application services that do not require access to network resources.
NetworkService
The NetworkService account was also introduced with Windows XP and Windows Server 2003 with the intent of providing a service account with fewer privileges. For the most part the NetworkService account has the same privileges as the LocalService account. The primary difference is that the NetworkService account can authenticate to network resources using the associated domain computer account. The domain computer account’s privileges to network resources can then be managed via Active Directory. As you may have guessed, the NetworkService account is commonly used to run application services that require access to network resources.
Both the LocalService account and NetworkService account may provide application services with more privileges than they really need. As a result , they are also more susceptible to privilege escalation attacks they may provide attackers with LocalSystem privileges.
Local User Accounts
Local user accounts can also be used to run application services that don’t require access to network resources. In fact, it is considered a much safer practice than using LocalService, because the account doesn’t have to be a part of the local Users group. As a result, administrators are able to assign only the privileges necessary to run the service application and nothing more.
Domain User Accounts
Domain user accounts created by a Domain Admin (or similar role) can be used to run an application services that requires access to network resources. Similar to local user accounts, domain user accounts can be configured with least privilege in mind, and don’t have to inherit the privileges of the local Users group and domain computer account. When configured correctly, using domain user accounts to run application services is considered to be the best practice.
How can service accounts be a threat?
I’d like to say that there is a silver bullet for this one, but I think we all know that in the real world they don’t exist. With that in mind I think that the information below can be used as a good starting point, but I haven’t addressed a lot of the implementation challenges that exist in most environments today.
Excessive Privileges
Administrators are just as guilty as vendors when it comes to setting excessive privileges on service accounts. Every time an administrator sets up the privileges for a service account they should be putting some serious thought into who might be getting that access indirectly. Let’s take database service accounts for example. For some reason a lot of administrators feel that MS SQL service accounts need to be a part of the Domain Admins group. What they aren’t realizing, is that by doing that they are also giving Domain Admin rights to anyone who can run a local command through the database server. That list could potentially include server administrators, database administrators, web application developers, and anyone on the Internet who can access the company’s website and use an SQL injection tool. I can’t tell you how many times an SQL injection issue on an Internet facing web application has landed me Domain Admin privileges in one step, because the principle of least privilege wasn’t considered. You may not see excessive privileges as a failing ASV finding, but in my opinion this is still one of the biggest threats found in large environments today.
Default and Weak Passwords
In many environments it’s still possible for internal attackers to enumerate valid domain users using SNMP, LDAP, SMB, and a number of other protocols. As a result, attackers can usually find a vendor defined service account with a default password. If you don’t have a good list of vendor passwords, plenty of them can be found online with Google. Google can also help you find vendor manuals for more obscure software that doesn’t make it onto the larger lists. If no vendor accounts can be identified, accounts with weak passwords also make great targets using tools like Enum+, Hydra, and Bruter. It’s important to note that this type of attack requires very little skill to execute, but can potentially have a dramatic business impact if sensitive information is accessible.
No Password Rotation or Expiration
Employees come and go from organizations all the time. Unfortunately, the same can’t be said for service account passwords. Basically, administrators don’t like to change them, and neither do vendors. This stagnation can create unnecessary risk. I know we like to trust the people in our companies, but we should still try to account for unforeseen circumstances that might motivate one of them to use a known service account password to do some damage. Also, if an attacker is able to recover the password (or hash) they may continue to use it to access network resources without alerting the IT group.
No Auditing or Alerting
Where there is no auditing there can be no alerting. Unfortunately actions taken by service accounts are not sufficiently audited in most environments. As a result, when an attacker leverages a service account to accesses confidential information not a single alert will be sent to notify administrators. Just so everyone is aware, if a tree falls in the woods and no one is there to hear it, it still makes a sound.
How can service accounts be secured?
There are quite a few ways that service accounts can create risk in an environment, but since this is a blog and not a book I’ve only listed the more common misconfigurations that lead to real business risk.
Use Local and Domain Accounts
Use local and domain user accounts to run application services. Doing so provides administrators with a way to remove potentially excessive privileges automatically inherited by LocalService and NetworkService accounts.
Apply the Principle of Least Privilege
Only assign necessary privileges to service accounts. Start with the most restrictive state possible and build out from there. Notorious offenders of excessive privileges include database accounts, backup accounts, and accounts used for clustering (to name but a few).
Disable the Ability to Login Interactively
Administrators can use group policy to prevent service accounts from being used to login interactively. This may be enough to prevent an unskilled attacker from using the account to escalate their privileges on compromised systems. However, please note that in some cases disabling interactive login may completely break your application.
Buy Products that can be Securely Configured
During product screening ensure vendor service accounts can be configured with least privilege and adhere to strong password policies. Default passwords should never be used. Also, put pressure on existing vendors to provide updates that will allow their product to be configured securely.
Enforce Strong Password Policies
Enforce password complexity and a length of at least eight characters at the local computer and domain levels to prevent attackers from easily guessing passwords. Also, if service account password expiration can’t be automated ensure that passwords are manually changed on a periodic basis.
Enable Auditing
Auditing should be enabled on service accounts to track significant actions such as account management changes, policies changes, and logon events. In the event of an incident, administrator should be able to use the logs to help track down the source of the issue.
A common approach is to perform auditing at the OU and local levels. However, in order to determine if accounts are performing unauthorized actions you really need to enable auditing on security groups and sensitive files as well.
Configure Alerting
Auditing is great for forensic activities, but to identify an attack in progress alerting will also need to be configured. Consider centralizing logs and setting up alerts to notify IT staff when significant events occurs. For example, it might be good to know if some is adding users to your Enterprise Admins group. There are a ton of tools available that perform alerting and log management. Some of the ones I see in environments on a regular basis include GFI EventsManager, OSSEC and Splunk.
Remove Unused Service Accounts
If an application or device that uses a service account is removed from the environment, the associated service account should also be removed. Perform periodic audits of service accounts to help identify accounts that need to be removed. To facilitate the process, the relative application owner should be made responsible for communicating to IT when accounts are no longer needed.
Keep a sharp eye on service accounts associated with test and demo accounts. They have a bad habit of sticking around, because people simply forget they are there. Also, virtual machines are responsible for some of the biggest service account sprawl to date, so make sure to watch out for these systems and services in your environment.
Final Thought
Service accounts basically run the show so we don’t have to, and in most environments they have access to all of the things that we hold near and dear to our hearts as IT professionals. That means sensitive data like credit card numbers (PCI), medical records (HIPAA) and social security numbers (PII). So when configuring service accounts give them the consideration they deserve.
Do you know about ALL of the systems on your network? If so, you’re in the minority. Identifying and actively managing all the systems on a network is not an easy task. Environments are constantly changing, asset owners come and go, and without a good asset management process, systems get lost in the shuffle. Unfortunately, many organizations don’t take asset management into account when developing their vulnerability management programs. As a result, systems are left unmanaged, misconfigured, and unpatched.
As you might guess, malware, attackers and penetration testers are often able use these systems as entry points and leverage their trust relationships to gain administrative control over the network. It’s hard to protect systems you don’t know are there, but there are some controls that can be put into place to reduce the risk they present to your environment.
What systems are typically affected?
Almost any system can drop off the radar, but usually they’re not high profile systems that require a lot of attention like domain controllers or critical application servers. In my experience, the systems most likely to fall through the cracks include test servers, and legacy application servers.
How can I get started doing asset management?
Good asset management starts with knowing what systems are on your network to begin with. So choosing an asset management solution and performing periodic device discovery on known network segments are good first steps. Once systems are identified they can be entered into the inventory and assigned an owner, asset value, and other data that can be used to prioritize IT tasks like vulnerability remediation. Below are some basic steps that can help network administrators get started:
Choose an asset management solution for your environment.
There are quite a few commercial and open source options available. Many of them are capable of performing dynamic device identification, but some of them are only able to find certain types of systems. Regardless, I recommend doing some independent research to find the one that works best for your environment and budget. Like most things, you get what you pay for, but below are few tools that I see being used on a fairly regular basis:
Perform periodic asset discovery on known network segments.
The goal of asset discovery is to basically identify any device on the network with an IP address. That includes everything from Windows mail servers to loading dock hand scanners. If it’s on the network, you want to know about it. As I mentioned before many of the commercial asset management tools have this functionality built in. However, I understand that not everyone has pockets lined with gold. So for the biggest bang for your buck I recommend Nmap. It’s incredibly flexible and comes at a great price (free). However, remember that ping scans by themselves aren’t enough. Many systems and networks are configured to drop ICMP requests, so it’s a good idea to perform some TCP and UDP scans as well.
Assign asset ownership & transfer asset ownership as necessary.
An asset owner’s role is very similar to that of a parent. They are responsible for the care and protection of their systems. As a result they perform such nurturing tasks as applying missing patches, implementing secure configurations, and maintaining up to date virus definitions. If there is no asset owner assigned to perform such duties for a system, it will eventually fold to an emerging vulnerability.
Assign an asset value to each system based on the potential business impact.
Typically this value is loosely based on the amount of revenue generated from the system; the type of information stored on the system, and the logical placement of the system on the network. However, keep in mind that the asset value doesn’t necessarily have to be a monetary. It could be a number 1 through 5. The point is having a method to help prioritize IT efforts.
How can I reduce the risk associated with unmanaged systems on my network?
This is a common question, and below are some common answers. Keep in mind that not all of them are appropriate for every environment.
Develop secure configuration baselines for each device type and operating system.
This will help to ensure that if a system drops off of the radar that at least it’s less likely to be susceptible to common attacks. Enforcing password complexity and account lockouts to help prevent brute force attacks is a basic example.
Conduct periodic audits on a sample of the configurations to verify compliance.
This will help to identify procedural gaps that may contribute to the implementation of insecure system configurations.
Perform periodic vulnerability scanning of systems.
This will help to identify common vulnerabilities on known systems. Once vulnerabilities are remediated, the systems will be less susceptible to common attacks.
Perform periodic patch scans and updates (OS and 3rd party applications).
Once vulnerabilities are remediated, the systems will be less susceptible to common attacks.
Implement Network Access Control Systems (NAC).
Implement a NAC that is capable of dynamic device detection and can quarantine systems that do not meet the minimum security requirements.
Implement Port Security.
Ensure vendors and employees can’t easily connect to the network by disabling unused network ports.
Final Thought
It is very common for penetration testers to leverage unmanaged systems as entry points that lead to complete network takeovers. The reality is that there are some unmanaged systems on every large network. So the bad news is that PCI, HIPAA, Personal Identifiable Information (PII), and the rest of your sensitive data is constantly being put at risk by these anonymous threats. The good news is that you have options. Hopefully the information in this blog gave you a place to start.
As an organization that performs a large volume of code reviews and penetration tests, NetSPI is frequently asked which type of application assessment is the best option. Your primary options are a code review or a web application penetration test. Both are recommended and both find many of the vulnerabilities commonly found in web applications as defined by the Open Web Application Security Project (OWASP) Top 10 (http://www.owasp.org). By themselves, neither a code review nor a web application penetration test find all of the vulnerabilities that threaten the application.
Why perform them?
Many regulations either require them or highly recommend them. For example, Payment Card Industry Data Security Standard (PCI-DSS) requires that either a code review or a web application vulnerability security assessment (web application penetration test) is performed annually on any web application that stores, processes or transmits credit cards (PCI Requirement 6.6). In addition, for payment application vendors (i.e. point-of-sale application, etc.) the PCI Payment Application Data Security Standard (PA-DSS) requires a code review and a penetration test targeting the OWASP Top 10.
Picking one over the other
Even though code reviews and web application penetration tests can find most of the same vulnerabilities, they look at the application differently and as a result their findings can differ. Typically both approaches find OWASP Top 10 issues such as SQL Injection, cross-site scripting (XSS), etc. However, the efficiency and effectiveness how each method finds these vulnerabilities can differ. For example, code reviews are better at finding most instances of input validation issues (i.e. XSS or SQL Injection). All of the automated code scanning tools NetSPI uses trace the data within the application from its entry point to its exit point. A web application penetration test can find these instances but it could take days or weeks to prove they exist in the application.
Web application penetration testing
A web application penetration test can uncover vulnerabilities from the outside looking in. These vulnerabilities can be related to configuration or versions. An example might be an older version of Apache with a chunked encoding overflow vulnerability (http://osvdb.org/838). Web application penetration tests can also uncover vulnerabilities that are related to the operation of the application, such as default or easily guessed credentials. Other types of vulnerabilities found by a web application penetration test include:
Access control (forced browsing, etc.)
Session hijacking
Vulnerabilities related to business logic
In addition, web application penetration testing can find these instances easier than a code review. This being said, I am talking about a third-party code review, not a code review done by a person or person familiar with the code or the company’s development processes. Automated source code analysis tools do not find these types of vulnerabilities. Manual testing can be done but could greatly inflate the cost of the code review.
Code Reviews
A code review looks at the application from the inside out. Vulnerabilities commonly found in a code review that cannot be easily found in an application penetration test include logging of sensitive data or application backdoors, as they are not exposed to the outside. Other types of vulnerabilities found by a code review include:
Denial of services caused by not releasing resources
Buffer overflows
Missing or poor error handling
Dangerous functions
Hardcoded password or keys in the source code
Code implementation problems
Missing or poor logging
Look at the statistics
NetSPI has found through our own experience that only a small subset of vulnerabilities found by code reviews and application penetration tests overlap. In NetSPI’s analysis, only 18% of the overall vulnerabilities found were discovered in both the code review and the web application penetration test where both services were performed on the same application (see Code Review Percentages pie chart below). Of the vulnerabilities found in the web application penetration tests, only 14% of the findings are found by both the web application penetration test and a code review (see Pen Test Percentages pie chart below).
Final Thoughts The most comprehensive approach to finding security vulnerabilities in web applications is performing both a code review and a web application penetration test. For critical applications, performing only one of these services can result in many vulnerabilities remaining within the application and unacceptable risk to the organization.
Every penetration tester has a toolkit they use for escalating their privileges on the network. In some cases, the tester will copy the toolkit over to a target system once it has been compromised. However, anti-virus software has gotten pretty good at catching tools commonly included in such toolkits. To get around this problem, many penetration testers simply disable the anti-virus services prior to copying over their toolkit. Usually, disabling Windows services is trivial, but some don’t shutdown as easy as we would like. This blog describes a relatively simple way to stop those resistant services.
Windows Services
Before we jump into it, let’s talk a little bit about Windows Services. Windows Services are applications that run quietly in the background and perform tasks that don’t usually require any user interaction (like anti-virus software). Each service is configured with a number of different settings that control how it operates. Service configurations could easily take up their own blog entry, but for the purpose of this blog I will be focusing on the “Startup Type” and “Service Type” settings.
Being the intuitive readers that you are, you may have already guessed that the “Startup Type” dictates how each service is started. Below are the startup types used by most Windows services:
Startup Types
Description
Automatic
If a service startup type is set to automatic it will automatically start each and every time the computer is restarted. It will start the service even if a user is not logged on.
Manual
If a service startup type is set to Manual it must be manually started by the user or application.
Disabled
If a service is Disabled it cannot be started until its start type has been changed to another option.
Each Windows service is also assigned a Service Type, which specifies how each service runs on the system. I’ve listed the two most common Windows service types below:
Service Type
Description
Win32_OWN_PROCESS
Win32 services that run as a stand-alone process.
Win32_SHARE_PROCESS
Win32 services that are capable of sharing address space with other services of the same type.
Additional configurations can also be set on the Service Type that determines how users and applications are allowed to control the service. Some of those configurations include:
NOT_STOPPABLE and STOPPABLE
NOT_PAUSABLE and PAUSABLE
IGNORES_SHUTDOWN and ACCEPTS_SHUTDOWN
If you’re wondering how the services are configured on your system issue the following command from the command line.
SC QUERY
Stopping Windows Services
Most of the services in Windows are configured to startup automatically as part of a shared process. Typically those services are also configured with the STOPPABLE, PAUSABLE, and ACCEPTS_SHUTDOWN settings so they can be managed by users and other applications. Those services can be easily stopped using the Services Management Console, the “SC” command, or the “NET STOP” command. For example:
SC STOP <SERVICENAME>
However, if a service is running as under its own process and configured as NOT_STOPPABLE it doesn’t always go down quite so easily. The standard method used to stop that type of service is to set its “Startup Type” to “Disabled” and then restart the system. That may be an option for a systems administrator, but it’s typically considered bad form to shutdown, or restart a system during a penetration test.
Stopping NOT_STOPPABLE Windows Services
Since I’m guessing most of you don’t want to restart the target server I am happy to provide an alternative. Corny as it may be, stopping a NOT_STOPPABLE service is as easy as 1-2-3.
First set the Startup Type to “Disabled”. This will prevent the service from restarting once it has been stopped. This can be done via the Services Management Console, “SC” command, or the registry. Just for fun I’ve provided an example of how to disable a service via the registry using the reg.exe application that comes with Windows.
For reference, I’ve also provided the other relative states and their associated registry values.
Registry Value
Startup Method
2
Automatic
3
Manual
4
Disabled
However, if you want to take the easy route you can also set the service state to “Disabled” via the following “SC” command:
SC CONFIG <SERVICENAME> start= disabled
Next identify the executable that the target service is running. Use the “SC” command to get the executable:
SC qc <SERVICENAME>
You should be able to see it running as an active task using the TASKLIST command:
TASKLIST | FIND /I “<EXECUTABLE>”
Finally use TASKKILL to terminate the process using the known executable:
TASKKILL /IM /F “<EXECUTABLE>”
Please keep in mind that you may have to be running as administrator or LocalSystem to stop the target service. There are a number of ways to get LocalSystem on a Windows system, but that’s a story for another day. However, if you’re interested in further reading on the subject I’ve provided links to some of my previous blogs in the references section below.
Conclusion
Killing some services can be be a pain, but the next time you run across a service that doesn’t want to stop for you, remember that you have options that don’t include restarting the server.
Subscribe to Application Security Blog
