This is part three of three posts on stronger passwords.

Part 1: Create stronger passwords and protect them

Part 2: Do you know your kids’ passwords?

The news is filled with stories about hackers cracking passwords. You can help avoid being a victim by never, ever using these passwords:

1. Password. Believe it or not, this is still a common password. Don’t use it.

2. Letmein. We recommend that you use passphrases that are memorable. Just don’t use this one. It ranks high on several lists of the most-used passwords.

3. Monkey. This common word appears on many lists of popular passwords. It’s also too short. Make passwords at least eight characters—the longer the better.

4. Your pet’s name. While you’re at it, don’t use any passwords that can be easily guessed, such as the name of your spouse or partner, your nickname, birth date, address, or driver’s license number.

5. 12345678. Avoid this and other sequences or repeated characters such as 222222, abcdefg, or adjacent letters on your keyboard (such as qwerty).

Bonus password tips

Don’t use the same password for multiple sites. Cybercriminals can steal passwords from websites that have poor security and then use those same passwords to target more secure environments, such as banking websites.

Change your passwords regularly, particularly those that safeguard your computer, important accounts (like email or Facebook), and sensitive information, like financial and health data.

For more password guidance, see Create strong passwords.

 

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

First step is duplicating the “Subordinate Certification Authority” template.

In Compatibility settings select Windows Server 2008:

Type a display name for the template:

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

In the Extensions tab select Key usage then Edit:

Put the checkbox on “Certificate signing” only

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

Right click on Certificate Templates, New, Certificate Template to Issue:

Select then newly created template then click OK:

The new template will then appear as available:

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

Select Active Directory Enrollment Policy then click Next:

Select the template then click Next:

Click on Details then Properties:

Enter a Common name then click Add:

Enter a friendly name for the certificate:

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

Ensure “Mark private key exportable is selected”:

In Select Hash Algorithm select “sha256”:

Then click OK, you will be asked to save the request to a file:

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerNameCAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerNameCAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerNameCAName>" "<CertificateResponse.cer>"

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

Ensure you export the private key:

Do not select any of the PFX options:

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

Click Next then select the DER format:

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

Notice that this certificate is signed using SHA256:

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer – Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

First step is duplicating the “Subordinate Certification Authority” template.

In Compatibility settings select Windows Server 2008:

Type a display name for the template:

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

In the Extensions tab select Key usage then Edit:

Put the checkbox on “Certificate signing” only

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

Right click on Certificate Templates, New, Certificate Template to Issue:

Select then newly created template then click OK:

The new template will then appear as available:

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

Select Active Directory Enrollment Policy then click Next:

Select the template then click Next:

Click on Details then Properties:

Enter a Common name then click Add:

Enter a friendly name for the certificate:

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

Ensure “Mark private key exportable is selected”:

In Select Hash Algorithm select “sha256”:

Then click OK, you will be asked to save the request to a file:

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerName\CAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerName\CAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerName\CAName>" "<CertificateResponse.cer>"

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

Ensure you export the private key:

Do not select any of the PFX options:

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

Click Next then select the DER format:

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

Notice that this certificate is signed using SHA256:

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer – Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

This is part three of three posts on stronger passwords.

Part 1: Create stronger passwords and protect them

Part 2: Do you know your kids’ passwords?

The news is filled with stories about hackers cracking passwords. You can help avoid being a victim by never, ever using these passwords:

1. Password. Believe it or not, this is still a common password. Don’t use it.
2. Letmein. We recommend that you use passphrases that are memorable. Just don’t use this one. It ranks high on several lists of the most-used passwords.
3. Monkey. This common word appears on many lists of popular passwords. It’s also too short. Make passwords at least eight characters—the longer the better.
4. Your pet’s name. While you’re at it, don’t use any passwords that can be easily guessed, such as the name of your spouse or partner, your nickname, birth date, address, or driver’s license number.
5. 12345678. Avoid this and other sequences or repeated characters such as 222222, abcdefg, or adjacent letters on your keyboard (such as qwerty).

Bonus password tips

Don’t use the same password for multiple sites. Cybercriminals can steal passwords from websites that have poor security and then use those same passwords to target more secure environments, such as banking websites.

Change your passwords regularly, particularly those that safeguard your computer, important accounts (like email or Facebook), and sensitive information, like financial and health data.

For more password guidance, see Create strong passwords.

 

In a previous article we explained how to create a self-signed CNG certificate, suitable for the HTTPS Inspection feature, which can be used to inspect sites using an SHA-256 certificate.

In this article we will explain how to generate a similar certificate using your internal CA based on Windows 2008 R2.

Using a certificate issued by your own CA, rather than a self-signed certificate, has the advantage that you will not have an additional certificate to distribute to the web proxy clients.
Bearing in mind that certificates have a limited validity period and that this eases operation maintenances, since you need only to change only the Subordinate CA certificate on TMG.

Arguably it can be said that if you set a validity period long enough, as some tenth of years, this would not be an issue.
But the truth is that what is considered secure today, might be easily compromised in a couple of years and for that reason, having an easy way to replace your certificates also improves your overall security.
The ability to quickly move to a larger key length or better hash algorithm at any time is the key to an always up to date and secure PKI infrastructure.

Now let's go ahead and create the certificate.
Begin by opening the Certificate Authority administration console, right click on Certificate Templates then Manage.

First step is duplicating the “Subordinate Certification Authority” template.

In Compatibility settings select Windows Server 2008:

Type a display name for the template:

Put the checkbox on “CA certificate manager approval” if you prefer to. If you do you will have to approve the request once submitted.

In the Extensions tab select Key usage then Edit:

Put the checkbox on “Certificate signing” only

Ensure the local Administrator, or your administrative user/group, has Enroll permissions:

Right click on Certificate Templates, New, Certificate Template to Issue:

Select then newly created template then click OK:

The new template will then appear as available:

Then open MMC, add the Certificates snap-in for the Local computer.

Open the Personal container, right click on Certificates, All Tasks, Advanced Operations, Create Custom request:

Select Active Directory Enrollment Policy then click Next:

Select the template then click Next:

Click on Details then Properties:

Enter a Common name then click Add:

Enter a friendly name for the certificate:

In the Private key tab ensure the CSP “Microsoft Software Key Storage Provider” is listed:

Ensure “Mark private key exportable is selected”:

In Select Hash Algorithm select “sha256”:

Then click OK, you will be asked to save the request to a file:

Open an elevated command prompt and execute the command:

certreq -submit -config "<ServerNameCAName>" "<CertificateRequest.req>" "<CertificateResponse.cer>"

The last parameter is required if you have not requested an approval before issuing the certificate.

If no approval is required a .cer will be retrieved, otherwise you will have to refer to the RequestID that will be displayed:

If the approval is required, once the request has been approved in the CA console, enter the following command to retrieve the .cer file:

certreq -retrieve -config "<ServerNameCAName>" <RequestID> "<CertificateResponse.cer>"

Then complete the request with the following command:

certreq -accept -config "<ServerNameCAName>" "<CertificateResponse.cer>"

At this point you will find the new certificate in the Personal store of the local computer and you can export it:

Ensure you export the private key:

Do not select any of the PFX options:

Provide the PFX password when requested and save the file.

Then export the certificate again, this time without the private key:

Click Next then select the DER format:

Click Next then save the .CER file.

Notice that the certificate you have just generated might be signed using the SHA1 Hash algorithm, although we have requested a certificate using SHA256 Hash Algorithm. This happens due to the fact that in some operating systems the Subordinate Certification Authority template forces the key hashing algorithm to be SHA1. This however does not prevent TMG from issuing (signing) certificates with SHA256 hash algorithms.

Also note that Microsoft is phasing out weaker certificates such as SHA1 certificates and certificates with keys under 1024 bits in length. So expect at some point in time this to change.

So don’t be surprised and go ahead with the next steps.

Copy the PFX and the CER files to the TMG box, open the HTTPS Inspection configuration and import the certificate form the PFX file:

Then save and apply the configuration

On the TMG server open an MMC console and add the Certificates snap-in for the local computer.
Then import the .cer file in the Intermediate certificate store.
You will need to restart the TMG server.

Importing the certificate in the Intermediate store is necessary for the TMG server to send the intermediate certificate in the certificate chain so that the client is able to build the trust chain.

This is further explained bellow.

Now you can try from a client browsing a site using a CNG certificate, such as Twitter.
You will see the certificate being signed by the new certificate from your CA:

Notice that this certificate is signed using SHA256:

Regarding the building of the certificate chain

Since the Subordinate CA Certificate (“TMG HTTPS Inspection CNG Ent.CA” in this case) is not published anywhere the clients can’t, on its own find the certificate SubCA certificate.

For a normal certificate issuing CA you would be able to publish the SubCA Certificate and publish to either a LDAP or HTTP location and the clients would be able to look it up, by downloading the certificate from the AIA Extension in the certificate.

In the case of TMG issued certificates, for HTTP inspection, these don’t have an AIA extension.

TMG will send both the certificate for the URL being accessed on the browser (or other client) and the Subordinate CA, configured in TMG to issue these certificates.

Otherwise the client would end up with a certificate that do not built up to a trusted root, having a "gap" in the chain. So as you can see bellow TMG will send the two certificates on “Server Hello” handshake.

The certificate generated, on the fly by TMG, for the HTTPS site you are visiting, will appear as being issued by an intermediate CA represented by the certificate you generated.

That is why it is essential to add the SubCA to the “Intermediate Certification Authorities” store for the “Local Computer”. Otherwise the TMG issued certificates would need to have the AIA sections which would require the intermediate certificate (the one you have just generated) to be published to a AIA location. This would require further configuration on your environment, so TMG provides some help in the Chain validation process and sends the intermediate CA in the "Certificate" section of the SSL handshake as we can see in the “Server Hello” handshake on the network capture above.

Your “Subordinate CA” (TMG HTTPS Inspection CNG Ent.CA) will then have an AIA Extension and from there up to the Root CA. As you can see from the image

This will then allow to build up a valid certificate chain ending up in your Internal CA and starting in the leaf certificate issued by TMG for HTTP Inspection. The bellow picture shows the expected Certificate chain.

 

Author:
Gianni Bragante
Support Engineer – Microsoft Forefront Edge Security Team

Luis Sousa
Support Engineer – Microsoft PKI/AD Team

Reviewer:
Philipp Sand
Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Every month for many years, we’ve released a number of updates focused on the continuous improvement of customers’ experiences with our technology. Historically, these updates happened at different times during the month, with the security-specific ones occurring on the second Tuesday of each month. Recently, to further streamline, we decided to include more of our non-security updates together with our security updates and begin the global release to customers on the second Tuesday of each month.

This month we had our first roll out with additional non-security updates. A small number of customers experienced problems with a few of the updates. As soon as we became aware of some problems, we began a review and then immediately pulled the problematic updates, making these unavailable to download. We then began working on a plan to rerelease the affected updates.

Today, we rereleased Security Bulletin MS14-045 to address kernel-mode driver issues, which you can learn more about through a review of the information contained here.

We encourage customers to install the security update as soon as possible. Customers with automatic updates enabled do not need to take any action. If you don’t have Windows Update enabled, we encourage you to do so now. If you’re not sure whether you’ve enabled Windows Update, you can check here. For organizations, your IT Group, the team or person administering the network, would be the best place to check.

Tracey Pretorius, Director
Microsoft Trustworthy Computing

UPDATE September 2, 2014: Today, we rereleased the August 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2.

Customers with Windows Updates enabled, and who have selected to receive optional updates automatically, do not need to take any action. Customers who have not selected to receive optional updates automatically, will need to go to Windows Update to install it.

For more information on this release, please visit the Windows blog.

Every month for many years, we’ve released a number of updates focused on the continuous improvement of customers’ experiences with our technology. Historically, these updates happened at different times during the month, with the security-specific ones occurring on the second Tuesday of each month. Recently, to further streamline, we decided to include more of our non-security updates together with our security updates and begin the global release to customers on the second Tuesday of each month.

This month we had our first roll out with additional non-security updates. A small number of customers experienced problems with a few of the updates. As soon as we became aware of some problems, we began a review and then immediately pulled the problematic updates, making these unavailable to download. We then began working on a plan to rerelease the affected updates.

Today, we rereleased Security Bulletin MS14-045 to address kernel-mode driver issues, which you can learn more about through a review of the information contained here.

We encourage customers to install the security update as soon as possible. Customers with automatic updates enabled do not need to take any action. If you don’t have Windows Update enabled, we encourage you to do so now. If you’re not sure whether you’ve enabled Windows Update, you can check here. For organizations, your IT Group, the team or person administering the network, would be the best place to check.

Tracey Pretorius, Director
Microsoft Trustworthy Computing

UPDATE September 2, 2014: Today, we rereleased the August 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2.

Customers with Windows Updates enabled, and who have selected to receive optional updates automatically, do not need to take any action. Customers who have not selected to receive optional updates automatically, will need to go to Windows Update to install it.

For more information on this release, please visit the Windows blog.

This is the second of two blog posts on password protection. Read Part 1: Create strong passwords and protect them.

Whether or not you should know all of your kids’ passwords depends on their age, how responsible they are, and your parenting values.

However, kids of any age and responsibility level need to know how to create strong passwords and how to protect those passwords.

Sharing is great, but not with passwords

Your kids should never give their friends their passwords or let them log on to their accounts. Also, be careful sharing your passwords with your kids.

3 strategies for strong passwords

• Length. Make your passwords at least eight (8) characters long.

• Complexity. Include a combination of at least three (3) uppercase and/or lowercase letters, punctuation, symbols, and numerals. The more variety of characters in your password, the better.

• Variety. Don’t use the same password for everything. Cybercriminals can steal passwords from websites that have poor security and then use those same passwords to target more secure environments, such as banking websites.

For more information, see Help kids create and protect their passwords.

This is the second of two blog posts on password protection. Read Part 1: Create strong passwords and protect them. Whether or not you should know all of your kids’ passwords depends on their age, how responsible they are, and your parenting values. However, kids of any age and responsibility level need to know how to create strong passwords and how to protect those passwords.

Sharing is great, but not with passwords

Your kids should never give their friends their passwords or let them log on to their accounts. Also, be careful sharing your passwords with your kids.

3 strategies for strong passwords

• Length. Make your passwords at least eight (8) characters long.
• Complexity. Include a combination of at least three (3) uppercase and/or lowercase letters, punctuation, symbols, and numerals. The more variety of characters in your password, the better.
• Variety. Don’t use the same password for everything. Cybercriminals can steal passwords from websites that have poor security and then use those same passwords to target more secure environments, such as banking websites.

For more information, see Help kids create and protect their passwords.

Revision Note: V2.0 (August 27, 2014): For MS14-045, bulletin revised to announce the replacement of the 2982791 update with the 2993651 update for all supported releases of Microsoft Windows. See the bulletin for details.
Summary: This bulletin summary lists security bulletins released for August 2014.

Severity Rating: Important
Revision Note: V3.0 (August 27, 2014): Bulletin rereleased to announce the replacement of the 2982791 update with the 2993651 update for all supported releases of Microsoft Windows. See the Update FAQ for details.
Summary: This security update resolves three privately reported vulnerabilities in Microsoft Windows. The most severe of these vulnerabilities could allow elevation of privilege if an attacker logs on to the system and runs a specially crafted application. An attacker must have valid logon credentials and be able to log on locally to exploit these vulnerabilities.

Severity Rating: Important
Revision Note: V3.0 (August 27, 2014): Bulletin rereleased to announce the replacement of the 2982791 update with the 2993651 update for all supported releases of Microsoft Windows. See the Update FAQ for details.
Summary: This security update resolves three privately reported vulnerabilities in Microsoft Windows. The most severe of these vulnerabilities could allow elevation of privilege if an attacker logs on to the system and runs a specially crafted application. An attacker must have valid logon credentials and be able to log on locally to exploit these vulnerabilities.

All week we’ll be posting our best guidance on how to create, protect, and manage your passwords.

Passwords are your first line of defense against hackers. Pick passwords that are difficult to crack but easy for you to remember.

What does “difficult to crack” mean?

Each time cybercriminals hack into a database of passwords, they learn more about the kinds of passwords that people use. (Come back on Friday to read Part 3 of our password series on what passwords you should never, ever use.) Now, even passwords that we think are tricky can be guessed by cybercriminals who’ve harnessed the right technology to crack passwords.

The best passwords are the most unpredictable

Stuart Schechter and other colleagues from Microsoft Research have developed a free online tool that helps you avoid passwords that are predictable. Try the tool.

A strong password:

• Contains at least eight characters.

• Does not contain your user name, real name, or company name.

• Does not contain a complete word.

• Is significantly different from previous passwords.

• Is different from passwords that you’ve used on other websites.

Get more advice on how to create strong passwords.

6 ways to protect your password

Once you’ve chosen a strong password, you can protect it from hackers by following a few simple rule:

1. Don’t share your password with friends.

2. Never give your password to people who call you on the phone or send unsolicited email, even if they claim to be from Microsoft.

3. Change your password regularly.

4. Tell your children not to share your passwords (or theirs) with anyone. Check back tomorrow for more guidance on how to help kids create and protect their passwords.

5. Evaluate password managers and other password tools carefully.  If they keep all your passwords in the cloud, they should use encryption. If the service has problems, understand that you might be locked out of your accounts.

6. Enable two-step verification. Two-step verification uses two ways to verify your identity whenever you sign in to your Microsoft account. Two-step verification is optional, but we recommend that you use it. Learn how to turn it on.

Learn more about how to protect your passwords.

All week we’ll be posting our best guidance on how to create, protect, and manage your passwords.

Passwords are your first line of defense against hackers. Pick passwords that are difficult to crack but easy for you to remember.

What does “difficult to crack” mean?

Each time cybercriminals hack into a database of passwords, they learn more about the kinds of passwords that people use. (Come back on Friday to read Part 3 of our password series on what passwords you should never, ever use.) Now, even passwords that we think are tricky can be guessed by cybercriminals who’ve harnessed the right technology to crack passwords.

The best passwords are the most unpredictable

Stuart Schechter and other colleagues from Microsoft Research have developed a free online tool that helps you avoid passwords that are predictable. Try the tool.

A strong password:

• Contains at least eight characters.
• Does not contain your user name, real name, or company name.
• Does not contain a complete word.
• Is significantly different from previous passwords.
• Is different from passwords that you’ve used on other websites.

Get more advice on how to create strong passwords.

5 ways to protect your password

Once you’ve chosen a strong password, you can protect it from hackers by following a few simple rule:

1. Don’t share your password with friends.
2. Never give your password to people who call you on the phone or send unsolicited email, even if they claim to be from Microsoft.
3. Change your password regularly.
4. Tell your children not to share your passwords (or theirs) with anyone. Check back tomorrow for more guidance on how to help kids create and protect their passwords.
5. Evaluate password managers and other password tools carefully.  If they keep all your passwords in the cloud, they should use encryption. If the service has problems, understand that you might be locked out of your accounts.

Learn more about how to protect your passwords.

We’ve noticed comments from many of you asking why we want you to verify your Microsoft security information. We’d like to explain why verifying this information is important. To help protect your email account and your personal data, we ask everyone who has a Microsoft account to make sure that the security information associated with their account is correct and up to date. When your security information (like an alternate email address or phone number) is current, we can use it to verify your identity.

For example, if you forget your password or if someone else tries to take over your account, Microsoft uses your security details to help you get back into your account.

If you see a message asking you to update or verify your Microsoft account security information, you have seven days to do it. If you no longer have access to your security information, you will have to fill out a support request.

Get a quick overview of how to add security info to your account

We’ve noticed comments from many of you asking why we want you to verify your Microsoft security information. We’d like to explain why verifying this information is important. To help protect your email account and your personal data, we ask everyone who has a Microsoft account to make sure that the security information associated with their account is correct and up to date. When your security information (like an alternate email address or phone number) is current, we can use it to verify your identity.

For example, if you forget your password or if someone else tries to take over your account, Microsoft uses your security details to help you get back into your account.

If you see a message asking you to update or verify your Microsoft account security information, you have seven days to do it. If you no longer have access to your security information, you will have to fill out a support request.

Get a quick overview of how to add security info to your account

Severity Rating: Important
Revision Note: V1.1 (August 20, 2014): Bulletin revised to add prerequisite information for customers running Windows Server 2003 who install updates manually. See Update FAQ for more information.
Summary: This security update resolves a privately disclosed vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker runs a specially crafted application that attempts to repair a previously-installed application. An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability.

Severity Rating: Important
Revision Note: V1.1 (August 20, 2014): Bulletin revised to add prerequisite information for customers running Windows Server 2003 who install updates manually. See Update FAQ for more information.
Summary: This security update resolves a privately disclosed vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker runs a specially crafted application that attempts to repair a previously-installed application. An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability.

Rogue antivirus software has been a part of the malware ecosystem for many years now – Win32/SpySheriff and Win32/FakeRean date all the way back to 2007. These rogues, and the many that have followed them throughout the years, generally mislead and scare users into paying a fee for "cleaning" false detections that the software claims to have found on the machine. They often use dozens of different brandings and name combinations in an attempt to hide, cover their tracks, and avoid our detections, all so the makers of the rogues continue to make revenue.

Lately we're seeing a dropping trend in the telemetry for some of the once most-prevalent rogue families, such as Win32/Winwebsec, Win32/OneScan, Win32/FakeXPA, Win32/FakePAV. Figure 1 shows this downward trend over the past year.

Figure 1: Monthly telemetry for top rogue families

 

This downward trend is also seen when looking at the top 10 rogue families per region.

Figure 2: Top 10 rogues in the Asia Pacific region

 

Figure 3: Top 10 rogues in the Europe, Middle East, and Africa region

  

Figure 4: Top 10 rogues in the Latin America region

 

Figure 5: Top 10 rogues in North America

 

It's likely this has happened due to the antimalware industry's intense targeting of these rogues in our products, and better end-user awareness and security practices. In particular, greater education about the social engineering technique the rogues use, and the large number of legitimate, free antivirus products available on the market appear to have had an impact on a user's willingness to pay for such pests. 

However, since the big malware "players" are having more trouble in taking advantage of users paying for fake security products, and are moving away from this kind of social engineering, we are seeing other players willing to fill the gap – luckily with small impact.

In the past we've regularly seen rogues use the hosts file to block access to a legitimate security product's websites to deny users protection against the threat.

Rogue:Win32/Defru has a different and simpler approach on how to trick the user and monetize on it. Basically, it prevents the user from using the Internet by showing a fake scan when using different websites.

When the user is browsing the Internet, the rogue will use the hosts file to redirect links to a rather infamous specific fake website (pcdefender.<removed> IP 82.146.<removed>.21) that is often used in social engineering by fake antivirus malware (see Figure 2).

The mechanism is depicted in the following picture when the user accesses Bing. Note how the user will still see the name of the site they were trying to access in the address bar.

Figure 6: Browser page where the user is redirected when accessing Bing

 

Rogues often target specific countries or regions. Defru appears to be targeting Russian speakers, as evidenced both by its warnings and infection telemetry:

Figure 7: Infections of Rogue:Win32/Defru in August 2014

 

The first message tries to imitate a Windows Security message which says (we've translated it from Russian here):

"Detected on your computer malicious software that blocks access to certain Internet resources, in order to protect your authentication data from intruders the defender system Windows Security ^® was forced to intervene."

The website promises a system clean, access to webpages, daily updates, and access to "Windows Security" and "Windows Defender", as in the following figure:

Figure 8: Translated fake scanner page

 

It will appear as a constant nuisance for the user as they try to access their desired website. We have a list of the websites it targets in the Rogue:Win32/Defru description – the list is over 300 entries long.

An unsuspecting user, after receiving this warning more than a few times when browsing, might be inclined to click "Pay Now". This will lead them to a payment portal called "Payeer" (payeer.com) that will display payment information (see Figure 3). It's linked to galafinance.com – a website that displayed a "Temporary busy" text when accessed and now is offline.

Figure 9: Payment service used by Win32/Defru

 

But of course, even if the user pays, the system will not be cleaned.

Win32/Defru is targeting Russian speaking users, mostly from Russia, Ukraine, and Kazakhstan.

The rogue is written in PHP, uses a PHP EXE compiler (Bambalam) and will copy itself to %appdata%\w1ndows_<4chars>.exe (e.g. "w1ndows_33a0.exe"). It persists at system reboot by adding itself to the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with the value "w1ndows_<4chars>".

Upon installation, the server is contacted and will reply with a simple "ok" to inform the connection is still alive.

The user can clean their system by removing the entry value from the "run" registry key, delete the file from disk and delete the added entries from the hosts file.

We want to remind you again that there are free security solutions such as Microsoft Security Essentials. Before paying for a product (either a security product or any other) make a thorough investigation to make sure that it is a legitimate product and it is not fake or a copy of a free one.

 

Daniel Chipiristeanu
MMPC

Ever wonder what your online image says about you? Do you constantly “check in” on social media, take daily selfies, or post the latest images of your kids? In an era of seemingly non-stop online sharing of our thoughts, images, and experiences, it’s important to understand the lasting impact our digital actions have on us and those around us.

US households have an average of 5.7 devices for personal and professional use, according to a recent Microsoft study. As this interconnectivity continues to grow, it’s not surprising that people and organizations, including employers or college recruiters for example, turn to social networking sites as a way to help assess potential candidates. Our same research, however, found that only a small percentage of global respondents take key steps to help manage their online reputations:

• 19 percent edited or deleted information to protect their online reputation;

• 15 percent used search engines to monitor and manage their personal information online; and

• 10 percent used a service to edit or delete information about themselves online

This tells me that as connected as we might be, we may not be doing all we can to manage our online personas. So, before kids, and even parents, educators, counselors, and coaches, head back to school, Microsoft wants each of us to make a personal commitment to #Do1Thing to set yourself up for digital success this school year. Visit Microsoft.com/SaferOnline to share your story and learn more about managing your digital life. On the interactive website, you can also:

• Take our social personality quiz: Which social media cliché are you?  Find out if you’re #HashtagHyper, a Click-Collector, or a One-Upper. Do you know someone who fits each profile? I bet you do.

• Share your results through social media for the chance to win a MS Nokia Lumia 2520 Red 10.1 Tablet with Windows RT 8.1(Verizon) in our #Do1ThingSweeps sweepstakes. 

• Watch our catchy video: It’s your social personality! Share this light-hearted piece with your social circles and help friends and family understand the potential impact of their online behavior.

• Finally, review each of our online reputation tips and enjoy the dog days of summer knowing you’ve completed your back-to-school checklist.

For more information about Microsoft’s work in Online Safety, visit our Safety & Security Center, “like” us on Facebook, follow us on Twitter, and look for my “point of view” following the #MSFTCOSO hashtag.