Archive for the ‘Security Related’ Category

All Systems Engineers, Administrators, Security Engineers, Information Security Consultants are worried most of the time on the password policies and the impact that may affect the entire organizations security. And they are absolutely right to worry about this more than anything else as you internals security these days are more worrying factor over the external ones.

You could have the best firewall solutions in place, you may had IPS/IDS, you may had the best NAC/NAP solutions implemented, PKI, encryption, bitlocker … etc. you name it!! Always consider if this any of these walls break, the next step for the attack is to take control over your resources by authenticating, which will require a user and password, once a privileged account’s password compromised, the pain starts.

 

In this article I will consider talking about field challenges to implement a balanced password policies between Maximum Security, business requirements and the ease of use in acceptable level.

 

Let us first look at the various attributes of domain password policies as per the best practices:

Attribute Microsoft Default Value Microsoft Recommended Value
Account lockout threshold 0 50
Reset account lockout counter after 0 15 minutes
Account lockout duration Not defined 15 minutes
Minimum password length 0 12 characters
Password must meet complexity requirements Disabled Enabled
Maximum password age 42 days 90 days
Minimum password age 0 1 day
Enforce password history 24 days 24 days

 

In the above table, these are the settings that you will see in the default domain policy in addition to the recommended values that Microsoft recommends to you to stay secure. The aim of the rough recommended values is to make you secure is in it? Although this remains a challenge to implement such strict recommendation.

All password policy attributes in the above table classified as “Critical” in severity risk classification as each one of these attributes has a vulnerability and countermeasures behind it. Not only that, the value combination plays a role on how each setting will affect other setting as they are fairly and strictly related, all these values in sum will define how far your password policy is security oriented.

To make it easier, I will assume that the readers of this article know what each password attribute means, in case u are not sure please follow this link for description of each attribute: http://technet.microsoft.com/en-us/library/hh994572(v=ws.10).aspx  

Now for each attribute, I will highlight each vulnerability, counter measures and potential impact.

Account lockout threshold

  • Vulnerability: If a bruit force attack targeted a user, this setting will minimize the number of attack attempts where after certain number of failed attempt the account will lock, however, a DoS attack can be performed across the domain by an attacker trying a series of password attacks against all domain users (don’t forget that Active Directory objects are readable by design for all authenticated users!!), if the number of attempts is greater than the lockout value, a Denial of users logon ability will take place.
  • Countermeasures: When the lockout value exists, a vulnerability to DoS may occur as described in the vulnerability. Here are some strong recommendation to overcome this vulnerability at the best:

o   Configure the Account Lockout Threshold setting to 0. This configuration ensures that accounts will not be locked out, and will prevent a DoS attack that intentionally attempts to lock out accounts. This configuration also helps reduce help desk calls because users cannot accidentally lock themselves out of their accounts. Because it will not prevent a brute force attack, this configuration should only be chosen if both of the following criteria are explicitly met:

1. The password policy requires all users to have complex passwords of 8 or more characters.

2. A strong audit methodology(s) is in place (e.g. SCOM ACS) to alert systems engineers when a failed logons occur in the environment.

o   Configure the Account Lockout Threshold setting to a high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack will still lock the account. A good recommendation for such a configuration is 50 invalid logon attempts, which will prevent accidental account lockouts and reduce the number of help desk calls but will not prevent a DoS attack (as discussed earlier). This option is recommended if your organization does not have complex password requirements and an audit policy that alerts administrators to a series of failed logon attempts.

  • Potential impact: If this policy setting is enabled, a locked-out account will not be usable until it is reset by an administrator or until the account lockout duration expires. This setting will likely generate a number of additional help desk calls. In fact, locked accounts cause the greatest number of calls to the help desk in many organizations. If you enforce this setting an attacker could cause a denial of service condition by deliberately generating failed logons for multiple user, therefore you should also configure the Account Lockout Duration to a relatively low value such as 15 minutes. If you configure the Account Lockout Threshold to 0, there is a possibility that an attacker’s attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place.

 

Reset account lockout counter after

  • Vulnerability: Users can accidentally lock themselves out of their accounts if they mistype their password multiple times. To reduce the chance of such accidental lockouts, the Reset account lockout counter after setting determines the number of minutes that must elapse before the counter that tracks failed logon attempts and triggers lockouts is reset to 0.
  • Countermeasures: Configure the Reset account lockout counter after setting to 15 minutes.
  • Potential impact: If you do not configure this policy setting or if the value is configured to an interval that is too long, a DoS attack could occur. An attacker could maliciously attempt to log on to each user’s account numerous times and lock out their accounts as described in the preceding paragraphs. If you do not configure the Reset account lockout counter after setting, administrators would have to manually unlock all accounts. If you configure this policy setting to a reasonable value the users would be locked out for some period, after which their accounts would unlock automatically. Be sure that you notify users of the values used for this policy setting so that they will wait for the lockout timer to expire before they call the help desk about their inability to log on.

 

 Account lockout duration

  • Vulnerability: A denial of service (DoS) condition can be created if an attacker abuses the Account lockout threshold and repeatedly attempts to log on with a specific account. Once you configure the Account lockout threshold setting, the account will be locked out after the specified number of failed attempts. If you configure the Account lockout duration setting to 0, then the account will remain locked out until an administrator unlocks it manually.
  • Countermeasures: Configure the Account lockout duration setting to an appropriate value for your environment. To specify that the account will remain locked until an administrator manually unlocks it, configure the value to 0. When the Account lockout duration setting is configured to a non-zero value, automated attempts to guess account passwords must wait for this interval before they resume attempts against a specific account. Using this setting in combination with the Account lockout threshold setting makes automated password guessing attempts more difficult.
  • Potential impact: Although it may seem like a good idea to configure this policy setting to never automatically unlock an account, such a configuration can increase the number of requests that your organization’s help desk receives to unlock accounts that were locked by mistake.

 

Minimum password length

  • Vulnerability: Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the account database so they can use tools to discover the accounts and passwords.
  • Countermeasures: Configure the Minimum password length setting to a value of 8 or more. If the number of characters is set to 0, no password will be required. In most environments, we recommend an 8-character password because it is long enough to provide adequate security but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the Passwords must meet complexity requirements setting in addition to the Minimum password length setting helps reduce the possibility of a dictionary attack. Note Some regions have legal requirements with respect to password length.
  •  Potential impact: Requirements for extremely long passwords can actually decrease the security of an organization, because users might leave the information in an insecure location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of help desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about pass phrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover. Note Older versions of Windows such as Windows 98 and Windows NT® 4.0 do not support passwords that are longer than 14 characters. Computers that run these older operating systems are unable to authenticate with computers or domains that use accounts that require long passwords.

 

Password must meet complexity requirements

  • Vulnerability: Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.
  • Countermeasures: When combined with a Minimum password length of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it will be difficult (but not impossible) for brute force attack to succeed. (If the Minimum password length setting is increased, the average amount of time necessary for a successful attack also increases).  
  • Potential impact: If the default password complexity configuration is retained, additional help desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetic characters. However, all users should be able to comply with the complexity requirement with minimal difficulty. If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper row characters. (Upper row characters are those that require you to hold down the SHIFT key and press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments. Also, the use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in unhappy users and an extremely busy help desk. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128–0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password).

 

Maximum password age

  • Vulnerability: The longer a password exists the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the Maximum password age setting to 0 so that users are never required to change their passwords is a major security risk because that allows a compromised password to be used by the malicious user for as long as the valid user is authorized access.
  • Countermeasures: Configure the Maximum password age setting to a value that is suitable for your organization’s business requirements. When configuring this setting you should also configure the Minimum password age to a value that makes sense in combination with this one.
  • Potential impact: If the Maximum password age setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization, because users might write their passwords in an insecure location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.

 

Minimum password age

  • Vulnerability: Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords are compromised and if an attacker is targeting a specific individual user account, with foreknowledge of data about that user, reuse of old passwords can cause a security breach. To address password reuse a combination of security settings is required. Using this policy setting with the Enforce password history setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history setting to ensure that users cannot reuse any of their last 12 passwords, they could change their password 13 times in a few minutes and reuse the password they started with, unless you also configure the Minimum password age setting to a number that is greater than 0. You must configure this policy setting to a number that is greater than 0 for the Enforce password history setting to be effective.
  • Countermeasures: Configure the Minimum password age setting to a value of at least 2 days. Users should know about this limitation and contact the help desk if they need to change their password during that 2-day period. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend. When configuring this setting you should also configure the Maximum password age to a value that makes sense in combination with this one.
  • Potential impact: If an administrator sets a password for a user but wants that user to change the password when the user first logs on, the administrator must select the User must change password at next logon check box, or the user will not be able to change the password until the next day.

 

 Enforce password history

  • Vulnerability: The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised will remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced. If you specify a low number for this policy setting, users will be able to use the same small number of passwords repeatedly. If you do not also configure the Minimum password age setting, users might repeatedly change their passwords until they can reuse their original password.
  • Countermeasures: Configure the Enforce password history setting to 24, the maximum setting, to help minimize the number of vulnerabilities that are caused by password reuse. For this setting to be effective in your organization, do not allow passwords to be changed immediately when you configure the Minimum password age setting. The Enforce password history value should be set at a level that combines a reasonable maximum password age with a reasonable password change interval requirement for all users in your organization.
  • Potential impact: The major impact of this configuration is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization but make them easier to guess. Also, an excessively low value for the Minimum password age setting will likely increase administrative overhead, because users who forget their passwords might ask the help desk to reset them frequently.

 

All the above recommendation are based on studies and analysis of real scenarios where your password policy pain points will suffer from. All the recommendations tackles variety of scenarios where you may consider to maximize the security along with ease of use (in a reasonable way).

Business requirements always play a main role, as security personnel, we always aim to maximize the security practices, this article helps you to guide a well-balanced approach on what could be done to achieve an acceptable level in security and make it aligned with the business needs and requirements.

 

Putting all together

Based on all of the above, I will give some examples where you can balance, compromise security in some settings where you still cover it in some others, these are just two examples, combinations could go to high number certainly, the examples just to make it easy to compile all the passwords attributes vulnerabilities, countermeasure and potential impact and put them all together in one big understanding vision

 

Example 1

Attribute Value Why
Account lockout threshold 40 Only if you will disable the complexity and lockouts auditing is enabled
Reset account lockout counter after 15 Reduce helpdesk calls and will avoid resetting the counter to Account lockout threshold 0. This setting always recommended to be 15 minutes in any password attributes combination
Account lockout duration 15 Always same value as Reset account lockout counter after
Minimum password length 8 – 12 When you have Account lockout threshold set to high number, a length of 8 and above will be sufficient
Password must meet complexity requirements Disabled When the Account lockout threshold is more than 40, you can disable
Maximum password age 90 This value is important to decrease the password where time frame of attack will be decreased, the lower value, the minimum surface attack will be. 90 days is the maximum value I recommend.
Minimum password age 1 1 day is the minimum in any case of attribues value combination, don’t ever put it 0, as this will make the password history obsolete, increasing it to more than 1 day is recommended optional
Enforce password history 24 days 24 is the recommended in any passwords attributes combinations, and there is no point to decrease it, why would a user re-use an old password again? Re-using passwords will increase the surface attacks for brute attackers where the guessing possibilities are easier.

 

Example 2

Attribute Value Why
Account lockout threshold 0 Only if you will Enable the complexity and minimum password length is 8 or higher, in addition to auditing of wrong passwords attempts usage
Reset account lockout counter after 15 Reduce helpdesk calls and will avoid resetting the counter to Account lockout threshold 0. This setting always recommended to be 15 minutes in any password attributes combination
Account lockout duration 15 Always same value as Reset account lockout counter after
Minimum password length 6 – 8 When you have Account lockout threshold set to 0, a length of 6 to 8 with Password must meet complexity requirements enabled is a must to decrease the possibility of brute force attack surface (not impossible)
Password must meet complexity requirements Enabled When the Minimum password length is equal or higher than 8, this settings is still highly recommended to balance security and make it difficult to brute force attach (not impossible)
Maximum password age 90 This value is important to decrease the password where time frame of attack will be decreased, the lower value, the minimum surface attack will be. 90 days is the maximum value I recommend.
Minimum password age 1 1 day is the minimum in any case of attributes value combination, don’t ever put it 0, as this will make the password history obsolete, increasing it to more than 1 day is recommended optional
Enforce password history 24 days 24 is the recommended in any passwords attributes combinations, and there is no point to decrease it, why would a user re-use an old password again? Re-using passwords will increase the surface attacks for brute attackers where the guessing possibilities are easier.

 

I hope this article were helpful and informative for you, please feel free to comment, add or ask if you find you may need any help.

Thank you J

Continued Security Oriented and Mac OS X Part1

The most important part in security for any OS as I mentioned, is how to keep it secure against the continuous vulnerabilities discovered by the security community and Hacker.

Mac OS X security lifecycle doesn’t include any clear security model or framework. the reason of mentioning that is the lack of a centralized repository for the security issues in Mac OS X, actually most of what you can find is a personal or some corporative work done by third party.

Mac OS X proved to be one of the highest vulnerable OS in the market today. Based on the latest study research done by Secunia http://secunia.com, Mac OS X till today has 1452 Vulnerabilities. this is on the Mac OS X side only. What do I mean by “Mac OS X side only”?

As mentioned in part one, Mac OS X is actually based on FreeBSD‘s and NetBSD‘s, so what Mac OS X actually is a FreeBSD, NetBSD and Mac OS X customization.

Mac OS X considered to be the User Mode of the Kernel, while FreeBSD is the kernel mode. on FreeBSD itself 84 Vulnerabilities, while the NetBSD is presenting the network kernel layer of the Mac OS X has 43 Vulnerabilities

So the total of infected vulnerability of a Mac System = Mac OS X + FreeBSD + NetBSD = 1579. this is a serious and dangerous number.

Now the criticality is not only in the number of vulnerability, the criticality relies beyond. The patching management is the key factor. you cannot find any reliable information in Mac OS X patching management as the absence of the patching cycle and addressing vulnerabilities and fixing them. Sure this doesn’t mean there is no patching or security implementation, but the absence of a clear resource and information about what has been patched and what not.

Some security advisory research keeps an eye to such changes, but still this is not the optimal way to handle a security for a well built promising OS like Mac OS X.

Generally speaking, all open source OS claims to be very secure, while the absence of a centralized repository for these multiple Linux and Unix-Like distributions is one of the concerns raised all the way.

OS popularity and the market share of use plays a huge role in orienting hacking against vulnerabilities, this why we find Windows Platform are more targeted to such exploits attempts. Windows 7 for example has 96 Vulnerabilities, where only 6 are not patched. which means, vulnerabilities are there, but they are well managed and handled by patches in a well known security cycle. Microsoft has a very nice Security Model called “SDLF – Security Development Life Cycle” which ensure developing applications against security standards to reduce the number of security breaches in MS Apps. the SDLF will not stop after producing the apps to the market, but it will continue improving security and addressing discovered vulnerabilities and work on patch them regularly following a nice model of Security Management.

Personally, I like Apple products and I am impressed with their quality build of hardware and the innovation part within it, but, what are the most important part, the soul of the outstanding hardware products, what about the Software? I hope in future Apple will take security more seriously apart from focusing on marketing and delivering nice looking products, spending some time in doing serious stuff is better than wasting all the time on marketing and presentations!!

If you are wondering about the FAN BOY WAR you hear here and there every day and every moment on the planet, then you should realize that nothing is real.

User experience, ease of use and much more functionalities are the major factors any user. but what about the hidden things!!!

Security of the platform you are using, is a fatal factor, not even important regardless you cannot touch it, play with it .. etc. actually, this topic is one of the hottest we find OS fans talking about, the fact is, most of the discussions I personally engaged in proofed for me most of FAN BOYS are repeating wrong information they received from …. WOW …. from another FAN BOYS!

“False Advertising”, this is the major headline about marketing OS.

One of the Headed IT Companies in advertisement is Apple. honestly, Apple is one of the best companies I ever find in advertising side. but False Advertising is a key in what I keep hearing about OS X like “Most Advanced OS” … “Secure OS” … “No Viruses” … “You don’t even need antivirus on Mac OS X” …. etc

Is this a joke?? ok let us move ahead and find out how much Mac OS X is secure. before I begin I must pointed out what is the meaning of Mac OS X.

Mac OS X is an OS relies on FreeBSD‘s and NetBSD‘s … so, there is no actual OS core “Kernel” built by Apple. Apple relies on (Mach kernel). this kernel developed at Carnegie Mellon University to support operating system research, primarily distributed and parallel computation.

Regardless the fact that Mac OS X developed by Apple is a GNU OS, Apple managed to build a great GUI experience on the GNU Kernel.

Let us talk business. Every OS by time will be part of security breaches attempts by hackers community world wide. and from there, hackers will focus on finding vulnerabilities in these OSes and try to develop an exploit to take advantage of the discovered vulnerability. it is very important here to point out that vulnerability doesn’t indeed means an exploit must happen. but the vulnerability itself is backdoor open for whoever able to realize how to reach it.

It will be silly to find someone fight or defend the fact of vulnerabilities because no OS, Application or any software is 100% un vulnerable. the main idea is, how to keep improving and securing your application/software to avoid the expected exploits of these vulnerabilities. so the management cycle of security is very important to follow.

Management Cycle of Vulnerabilities is the weakest part in Mac OS X. I don’t ant to point out any certain vulnerability yet, but pointing the UN PATCHED vulnerability what does matter.

A Framework of security management is a key in any security oriented model. This framework should include for example:

  • Monitoring discovered vulnerability in a certain cycles.
  • Assess discovered vulnerabilities against all possible exploits through it.
  • Work on patching these vulnerabilities, to be moved from unpatched to patched.
  • Release patches in well managed timing for users (this for moderate and low vulnerabilities)  and immediate patches for critical/fatal ones.

Apple doesn’t have any Security Newsletter advisory on Mac OS X, and there is actual alerting system to the users about any vulnerabilities. The worst is the absence of the security focus mechanism. a good aspect about this mess is the released updates for Mac OS X, there is no periodical updates, instead, you will find between time to time a patches with huge size. and you will find no actual information about what this update do.

Some sources mentioned about the absence of a Security Engineering section in Apple, still I cannot confirm this information, but it is most likely could be true based on the facts mentioned above, and the later completion of this article in its further parts.