Archive

Archive for September, 2013

Remote Assistance 101

September 26th, 2013 No comments

What is Remote Assistance?

Windows Remote Assistance makes it easy for you to get computer help from someone you trust, such as a friend or technical support person whom you have contacted. The helper can use Remote Assistance to connect to your computer and walk you through a solution—even if that person isn’t nearby. You can also help someone else the same way.

When you use Remote Assistance, the helper can view your computer screen and chat with you about what you both see. With your permission, your helper can even use his or her own mouse and keyboard to control your computer and show you how to fix a problem.

To help ensure that only people you invite can connect to your computer by using Windows Remote Assistance, all sessions are encrypted and password protected.

Does Microsoft make unsolicited phone calls offering help using Remote Assistance?

Microsoft and Microsoft partners will never call you to charge you for computer fixes; if you receive a call from someone claiming to be from Microsoft offering such a “service,” the call is not legitimate.

For more information, see Avoid tech support phone scams.

How do I get help by using Remote Assistance?

There are two ways to get help by using Windows Remote Assistance. If both you and your helper are running Windows 7, Windows 8, or Windows RT on your computers, you can use Easy Connect. Otherwise, use an invitation file.

To get step-by-step directions for both of these methods, see Windows Remote Assistance: Frequently asked questions.

Getting an Error “You have attempted to access a restricted URL” while accessing an application published through Forefront Unified Access Gateway

September 26th, 2013 No comments

 

Recently, I worked on a case where the customer had published multiple web applications using the template ‘Other Web Application (Application Specific Hostname)’.  The application type was specified as “web”.  When users accessed some of the applications, it worked but while accessing the rest, they were getting the error “You have attempted to access a restricted URL” (screenshot below)

 

clip_image001

 

When we checked the UAG Web Monitor logs, we got the following information about the user request

Warning        09/19/2013 15:45:21        67        URL Path Not Allowed        Security        Trunk1 (S)       UAG1        A request from source IP address **.**.**.**, user ***** on trunk Trunk1; Secure=1 for application Web Application1 of type Web failed. The URL /test/default.aspx contains an illegal path. The rule applied is Default rule. The method is GET. “

So, it appeared that UAG was not able to match the URL with any of the configured URL sets on that particular trunk where these applications were published.  And because of that our request was getting denied by the default rule.

Next, we checked the URL Set to see if we have created rules that would allow the required URL paths. The rule naming format is based on the Application Type specified at the time of creation of the application.  Rules beginning with ‘<ApplicationType>_’ only will be applied for the corresponding applications.  In our case, we had the following configuration:

 

clip_image003

 

So, we checked the URL Set for rules that begin with web_ .  We could see only one rule present matching that naming convention (web_Rule1).  This allowed all the paths.

 

clip_image005

 

So, this URL Set rule should have taken care of all the paths accessed by the clients, but still, we had an inconsistency in the behavior since some applications did not generate this error, while others did.

Now you must be wondering that when we already have a Rule for that application which allows everything, then why we are still getting Denied.  Please pay attention to the name of the Application Type and the name of the Rule under URL Sets.  As you can see, they have been configured in different cases, as in, Application type has W in upper case and the Rule name is completely in lower case.  And that’s what looked to be the cause behind the request not being able to match with the Rule.

So, we added another rule to the Ruleset and named it Web_Rule2 and allowed all the paths that were required. After this, users were able to successfully access the published application.

The key Takeaway is that URL set rules are case sensitive and care must be taken while writing rules for user-defined application types.

I hope this post helps you in resolving such issues that you may run into during your deployment.

 

Author:

Karthik Divakaran

Security Support Engineer – Microsoft Forefront Edge Team

Reviewers:

Nitin Singh

Security Support Escalation Engineer – Microsoft Forefront Edge Team

Richard Barker

Security Sr. Support Escalation Engineer – Microsoft Forefront Edge Team

Categories: Uncategorized Tags:

Mevade and Sefnit: Stealthy click fraud

September 26th, 2013 No comments

​Recently Trojan:Win32/Mevade made news for being the first large botnet to use Tor to anonymize and hide its network traffic. Within a few weeks, starting mid-August, the number of directly connecting Tor users increased by almost 600 percent – from about 500,000 users per day to more than 3,000,000.

Last week we concluded, after further review, that Mevade and Sefnit are the same family and our detections for Mevade have now been moved to join the Sefnit family.

Win32/Sefnit is a well-known family which includes a component capable of performing click fraud. From our observations in the wild, this particular component disappeared near the end of 2011. In June 2013 we discovered a new click fraud component which we originally classified as Mevade.  

Despite its recent notoriety due to the Tor activity, there is still a bit of mystery around how the latest version of Sefnit is spreading and the monetization techniques it uses.

In this blog I’ll be going into a bit more detail on the new stealthy click fraud technique used and how it has contributed to Sefnit being largely undetected by AV vendors for the last couple of years. Additionally, we will discuss a few of the attack vectors used by the Sefnit authors to deliver the latest version of the malware.

Interestingly, TrendLabs now believe they have identified the online identities of the actors behind the threat.

An interconnected threat

The Sefnit threat is composed of multiple components dedicated to different tasks. Among the observed samples, we have identified three distinct components. Figure 1 illustrates what is known currently about how these components interconnect as well as their intended purpose. Figure 2 provides sample references.

The Sefnit malware structure

Figure 1: The Sefnit malware structure

 
 
Component
Sha1 Subset
Service Name
Updater and Installer Service
Trojan:Win32/Sefnit.AU
5451cfa12c9acfae6e91f7c13e4b946038bacef4
942860bedf408cc4c6a1831ef3744a3f9e68b375
Adobe Flash Player Update Service”
Click Fraud Service
Trojan:Win32/Sefnit.AS
014ace48897e81052b9552a5a7ab04d00a8e5227
04bb63c3c71b4d033f49434f59a9225d08b4ea70
05a8fb5e61aad8be003a0ab461b39a86767fda23
0e246f6b95a9fd2d2a0c905be87074f5aadc7be0
0f8be849f287cf705ebc0409527fd06670438470
21bfcc14ac5abc6cb8b6fc802038e66ac4e24686
2d10aaf57c45bde69d8f52e23bdabc10a192da20
5d28316acb73e06a5f4c00858b3bf095cfe6b2bf
72d705af606df58aaaec3cc271f46d3d2e4c0499
7c5091177ea375eb3d1a4c4a2bbd5eb07a4cc5cc
8528769281709abd231a46f13ffdfaaa13232336
89c28f7203f9db0762d1c64e42422a5d89c6a83f
a6b055df9ad3d374acaf2dfacded3ba88d20f5cd
a7a41a0c6998f83839c5c6b58840b62a28714b17
a81b04724ab71e4a71e939204e476bb762adc506
bf4151bece1d94d8304df46b2598c14214d9834e
c5af760e62f230ed0f55ff19d2c2215568e6a199
ccd1fa1bf48665270128700bc94043c5fec39984
Trusted Installer”
 
“Bluetooth LE Services Control Protocol”
Peer-to-peer File Seeding Service and More
Trojan:Win32/Sefnit.AT
Trojan:Win32/Sefnit.gen!D
1aba915c0f75432f788fa672a6c7798af5acc94e
5afaadfe20c4776d12001212dc579f5d3851852b
9378acb5a7b6368e07ac2953459be911a84686cc
9dbca75ff98d49bdd211a2a7c8cac506789d6d29
a1733ba81255104c91e916943bb96875bf39d4d9
a5dd1b1d6105a773d1bdbdf961d36be2bbc56de1
abbd69ddb25b1b95c944b8fdb9531963556ea666
b55051915a2cc1a58284679d7753b55cb11bd9b0
d149bb1c2a4767f538a3de4d72f0a5d21ae46165
d95eb268e489928ed3d4bad8f56c0aa9ba0f0160
e50aa43d2df250ec56c92b4efd8df83e440cb167
edc7a434f18424d73c1403a15ee417fbd59eea95
Windows Internet Name Service”
Software Bundlers
Trojan:Win32/Sefnit.AU
c5758309136cd1e7e804d2003dc5ca27ae743ac3
n/a
 
Figure 2: Known Trojan:Win32/Sefnit Components
 

Sefnit’s stealthy new click fraud methodology

The new Sefnit click fraud method is a departure from the method previously used back in 2011. This new, stealthier methodology is believed to be largely responsible for Sefnit being able to evade AV vendor detection during the last couple of years.

The old version of Sefnit relied on click hijacking for performing click fraud. When an infected user was browsing the internet and clicked on a search engine result (such as from Google), sometimes the clicks would be hijacked to travel through advertising agencies to a similar webpage as the intended destination. These clicks are generally considered quite high-value and are hard to detect from an anti-fraud perspective.

Although this is very stealthy from an advertising agency anti-fraud data analytics perspective, it is not stealthy for the user whose click was hijacked. If detection was missing, some observant users would realize they did not land at the intended website, investigate the cause, and submit samples to antimalware researchers for detection. As a result this always brought attention to the malware.

In 2011, the Sefnit authors were observed to have stopped releasing new versions of the component responsible for this click hijacking and consequently were later believed to no longer be active in the wild. At the end of June 2013, we rediscovered Sefnit using a new click fraud strategy.

The Sefnit click fraud component is now structured as a proxy service based on the open-source 3proxy project. The botnet of Sefnit-hosted proxies are used to relay HTTP traffic to pretend to click on advertisements.

In this way, the new version of Sefnit exhibits no clear visible user symptoms to bring attention to the botnet. This allowed them to evade attention from antimalware researchers for a couple years. The figure below illustrates how the hosted 3proxy servers are used to relay Internet traffic through the botnet clients to perform a fake advertisement click.

The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

Figure 3: The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

A recorded example of this click fraud path is shown below by using the legitimate affiliate search engine mywebsearch.com to simulate a search for “cat” and fake a click on an advertisement provided by Google to defraud the advertiser Groupon.

The landing page for this click fraud instance

Figure 4: The landing page for a click fraud instance

The end result is Groupon paying a small amount of money for this fake advertisement “click” to Google. Google takes a portion of the money and pays the rest out to the website hosting the advertisement – mywebsearch. The Sefnit authors likely signed up as an affiliate for mywebsearch, resulting in the Sefnit criminals then receiving a commission on the click.

Sefnit authors avoid raising red flags on their advertisement affiliate accounts by preceding each clickfraud incident with a large time-gap and simulated normal user Internet browsing behaviour.

From experience, the interval between click fraud incidents is once per multiple-day period or longer. If the trojan simulates fake advertisement clicks too quickly, the anti-fraud team within the advertising agency would be able to detect the fraud, cancel the payout to the affiliate, and return the money to the defrauded advertisers.

Delivery by File Scout

We have been able to identify some of the infection vectors for the new version of Sefnit. One of the prominent methods is an installer for an application called “File Scout.” When this application is installed, it will also install Trojan:Win32/Sefnit silently in the background:

File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

Figure 5:  File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

The installed File Scout application is a tool that replaces the standard “Open with” dialog for unrecognized files with a new dialog:

File Scout replacement for the “Open With” dialog

Figure 6:  File Scout replacement for the “Open with” dialog

There is evidence suggesting that this File Scout application is developed by the Trojan:Win32/Sefnit developers. Specifically, it expects a similar format xml structure for the C&C-download and execute commands, both applications are distributed together, and the two applications were compiled 15 minutes apart with the same compiler.

Similarly, Trojan:Win32/Sefnit bears code similarity to some InstallBrain software bundler installers, such as the same string encryption algorithm and the same packer.

We have also seen Trojan:Win32/Sefnit spread through the eMule peer-to-peer file network.

Downloading and running files from any peer-to-peer network as well as downloading applications from untrusted sources puts you at a high risk of being infected by malware.

This latest version of Sefnit shows they are using multiple attack vectors, even going as far as writing their own bundler installers to achieve the maximum number of infections that make this type of clickfraud a financially viable exercise.

The authors have adapted their click fraud mechanisms in a way that takes user interaction out of the picture while maintaining the effectiveness. This removal of the user-interaction reliance in the click fraud methodology was a large factor in the Sefnit authors being able to stay out of the security-researchers’ radars over the last couple of years.

Microsoft is working towards thwarting this type of crime as we describe in another blog, “Another way Microsoft is disrupting the malware ecosystem.” The more computers we can protect, the less financially viable this type of malware becomes.

We will continue to monitor the family and keep detection in place to limit further fraud by the criminals.

Geoff McDonald

MMPC

 

Categories: Uncategorized Tags:

Mevade and Sefnit: Stealthy click fraud

September 26th, 2013 No comments

​Recently Trojan:Win32/Mevade made news for being the first large botnet to use Tor to anonymize and hide its network traffic. Within a few weeks, starting mid-August, the number of directly connecting Tor users increased by almost 600 percent – from about 500,000 users per day to more than 3,000,000.

Last week we concluded, after further review, that Mevade and Sefnit are the same family and our detections for Mevade have now been moved to join the Sefnit family.

Win32/Sefnit is a well-known family which includes a component capable of performing click fraud. From our observations in the wild, this particular component disappeared near the end of 2011. In June 2013 we discovered a new click fraud component which we originally classified as Mevade.  

Despite its recent notoriety due to the Tor activity, there is still a bit of mystery around how the latest version of Sefnit is spreading and the monetization techniques it uses.

In this blog I’ll be going into a bit more detail on the new stealthy click fraud technique used and how it has contributed to Sefnit being largely undetected by AV vendors for the last couple of years. Additionally, we will discuss a few of the attack vectors used by the Sefnit authors to deliver the latest version of the malware.

Interestingly, TrendLabs now believe they have identified the online identities of the actors behind the threat.

An interconnected threat

The Sefnit threat is composed of multiple components dedicated to different tasks. Among the observed samples, we have identified three distinct components. Figure 1 illustrates what is known currently about how these components interconnect as well as their intended purpose. Figure 2 provides sample references.

The Sefnit malware structure

Figure 1: The Sefnit malware structure

 
 
Component
Sha1 Subset
Service Name
Updater and Installer Service
Trojan:Win32/Sefnit.AU
5451cfa12c9acfae6e91f7c13e4b946038bacef4
942860bedf408cc4c6a1831ef3744a3f9e68b375
Adobe Flash Player Update Service”
Click Fraud Service
Trojan:Win32/Sefnit.AS
014ace48897e81052b9552a5a7ab04d00a8e5227
04bb63c3c71b4d033f49434f59a9225d08b4ea70
05a8fb5e61aad8be003a0ab461b39a86767fda23
0e246f6b95a9fd2d2a0c905be87074f5aadc7be0
0f8be849f287cf705ebc0409527fd06670438470
21bfcc14ac5abc6cb8b6fc802038e66ac4e24686
2d10aaf57c45bde69d8f52e23bdabc10a192da20
5d28316acb73e06a5f4c00858b3bf095cfe6b2bf
72d705af606df58aaaec3cc271f46d3d2e4c0499
7c5091177ea375eb3d1a4c4a2bbd5eb07a4cc5cc
8528769281709abd231a46f13ffdfaaa13232336
89c28f7203f9db0762d1c64e42422a5d89c6a83f
a6b055df9ad3d374acaf2dfacded3ba88d20f5cd
a7a41a0c6998f83839c5c6b58840b62a28714b17
a81b04724ab71e4a71e939204e476bb762adc506
bf4151bece1d94d8304df46b2598c14214d9834e
c5af760e62f230ed0f55ff19d2c2215568e6a199
ccd1fa1bf48665270128700bc94043c5fec39984
Trusted Installer”
 
“Bluetooth LE Services Control Protocol”
Peer-to-peer File Seeding Service and More
Trojan:Win32/Sefnit.AT
Trojan:Win32/Sefnit.gen!D
1aba915c0f75432f788fa672a6c7798af5acc94e
5afaadfe20c4776d12001212dc579f5d3851852b
9378acb5a7b6368e07ac2953459be911a84686cc
9dbca75ff98d49bdd211a2a7c8cac506789d6d29
a1733ba81255104c91e916943bb96875bf39d4d9
a5dd1b1d6105a773d1bdbdf961d36be2bbc56de1
abbd69ddb25b1b95c944b8fdb9531963556ea666
b55051915a2cc1a58284679d7753b55cb11bd9b0
d149bb1c2a4767f538a3de4d72f0a5d21ae46165
d95eb268e489928ed3d4bad8f56c0aa9ba0f0160
e50aa43d2df250ec56c92b4efd8df83e440cb167
edc7a434f18424d73c1403a15ee417fbd59eea95
Windows Internet Name Service”
Software Bundlers
Trojan:Win32/Sefnit.AU
c5758309136cd1e7e804d2003dc5ca27ae743ac3
n/a
 
Figure 2: Known Trojan:Win32/Sefnit Components
 

Sefnit’s stealthy new click fraud methodology

The new Sefnit click fraud method is a departure from the method previously used back in 2011. This new, stealthier methodology is believed to be largely responsible for Sefnit being able to evade AV vendor detection during the last couple of years.

The old version of Sefnit relied on click hijacking for performing click fraud. When an infected user was browsing the internet and clicked on a search engine result (such as from Google), sometimes the clicks would be hijacked to travel through advertising agencies to a similar webpage as the intended destination. These clicks are generally considered quite high-value and are hard to detect from an anti-fraud perspective.

Although this is very stealthy from an advertising agency anti-fraud data analytics perspective, it is not stealthy for the user whose click was hijacked. If detection was missing, some observant users would realize they did not land at the intended website, investigate the cause, and submit samples to antimalware researchers for detection. As a result this always brought attention to the malware.

In 2011, the Sefnit authors were observed to have stopped releasing new versions of the component responsible for this click hijacking and consequently were later believed to no longer be active in the wild. At the end of June 2013, we rediscovered Sefnit using a new click fraud strategy.

The Sefnit click fraud component is now structured as a proxy service based on the open-source 3proxy project. The botnet of Sefnit-hosted proxies are used to relay HTTP traffic to pretend to click on advertisements.

In this way, the new version of Sefnit exhibits no clear visible user symptoms to bring attention to the botnet. This allowed them to evade attention from antimalware researchers for a couple years. The figure below illustrates how the hosted 3proxy servers are used to relay Internet traffic through the botnet clients to perform a fake advertisement click.

The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

Figure 3: The Sefnit botnet uses the hosted 3proxy servers to redirect internet traffic and perform fake advertisement clicks

A recorded example of this click fraud path is shown below by using the legitimate affiliate search engine mywebsearch.com to simulate a search for “cat” and fake a click on an advertisement provided by Google to defraud the advertiser Groupon.

The landing page for this click fraud instance

Figure 4: The landing page for a click fraud instance

The end result is Groupon paying a small amount of money for this fake advertisement “click” to Google. Google takes a portion of the money and pays the rest out to the website hosting the advertisement – mywebsearch. The Sefnit authors likely signed up as an affiliate for mywebsearch, resulting in the Sefnit criminals then receiving a commission on the click.

Sefnit authors avoid raising red flags on their advertisement affiliate accounts by preceding each clickfraud incident with a large time-gap and simulated normal user Internet browsing behaviour.

From experience, the interval between click fraud incidents is once per multiple-day period or longer. If the trojan simulates fake advertisement clicks too quickly, the anti-fraud team within the advertising agency would be able to detect the fraud, cancel the payout to the affiliate, and return the money to the defrauded advertisers.

Delivery by File Scout

We have been able to identify some of the infection vectors for the new version of Sefnit. One of the prominent methods is an installer for an application called “File Scout.” When this application is installed, it will also install Trojan:Win32/Sefnit silently in the background:

File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

Figure 5:  File Scout installer that silently installs Trojan:Win32/Sefnit as the same time

The installed File Scout application is a tool that replaces the standard “Open with” dialog for unrecognized files with a new dialog:

File Scout replacement for the “Open With” dialog

Figure 6:  File Scout replacement for the “Open with” dialog

There is evidence suggesting that this File Scout application is developed by the Trojan:Win32/Sefnit developers. Specifically, it expects a similar format xml structure for the C&C-download and execute commands, both applications are distributed together, and the two applications were compiled 15 minutes apart with the same compiler.

Similarly, Trojan:Win32/Sefnit bears code similarity to some InstallBrain software bundler installers, such as the same string encryption algorithm and the same packer.

We have also seen Trojan:Win32/Sefnit spread through the eMule peer-to-peer file network.

Downloading and running files from any peer-to-peer network as well as downloading applications from untrusted sources puts you at a high risk of being infected by malware.

This latest version of Sefnit shows they are using multiple attack vectors, even going as far as writing their own bundler installers to achieve the maximum number of infections that make this type of clickfraud a financially viable exercise.

The authors have adapted their click fraud mechanisms in a way that takes user interaction out of the picture while maintaining the effectiveness. This removal of the user-interaction reliance in the click fraud methodology was a large factor in the Sefnit authors being able to stay out of the security-researchers’ radars over the last couple of years.

Microsoft is working towards thwarting this type of crime as we describe in another blog, “Another way Microsoft is disrupting the malware ecosystem.” The more computers we can protect, the less financially viable this type of malware becomes.

We will continue to monitor the family and keep detection in place to limit further fraud by the criminals.

Geoff McDonald

MMPC

 

Categories: Uncategorized Tags:

System Center Community/MVP Update

September 25th, 2013 No comments

As many of you have probably seen today, I have announced my resignation from Microsoft to go to a System Center partner company.  Friday will be my last official day at Microsoft, but I don’t plan on changing my personal level of commitment to the System Center community.  I’ll still be blogging, answering questions on forums, presenting at conferences, and working very closely with Microsoft on channeling the feedback I see on the community into building great solutions.

For me, this move is simply one of those situations where it was an opportunity for me to feed my inner entrepreneur and software developer.  System Center is alive and well.  Amazing things are happening and will continue to happen.  I’m excited to continue to be a part of the evolution of System Center, albeit in a different role.

I recently hired System Center MVP Christian Booth (@chbooth) to my team at Microsoft.  I am especially thankful today that he is filling my shoes.  He is an outstanding community contributor, extremely knowledgeable about System Center, and influential inside and out of Microsoft.  He has been and will continue to manage Microsoft’s relationship with the System Center Cloud and Datacenter Management MVPs and community at large.

Microsoft also has a phenomenal team of people sitting literally right next to Christian that are producing really great content around Windows Server and System Center on the Building Clouds blog.  Definitely check that out!

Microsoft is committed to community.  I’m committed to the community.  Not much really changes except for my email address.  I’ll see you out there!

Categories: Uncategorized Tags:

End of support for Java SE 6

September 24th, 2013 No comments

​If you’re running Java SE 6, we have some news for you: Oracle stopped providing public updates to it after February 2013.

Enterprise customers will still have access to long term help through their support channels.

For everyone else, you should upgrade to Java SE 7 and remove Java SE 6 – remember Java doesn’t remove older versions by default. 

Malware exploiting vulnerabilities in Java isn’t new. We’ve written about Java vulnerabilities on this blog before. In fact, since July this year Exploit:Java/CVE-2013-2465 has been making the rounds and targeting Java SE 6.

Oracle has done a great job of releasing Java updates to patch these vulnerabilities.

However, Java SE 6 is about seven years old, and Java SE 7 was released more than two years ago. This means it’s time to think about alternatives for the aging version.

While we’re talking about end-of-support software – technical assistance for Windows XP will no longer be available from April 8, 2014.

This includes the updates that help protect your PC against security risks and malware. It’s a good time to think about installing Windows 8 on your PC.

 

Categories: Uncategorized Tags:

End of support for Java SE 6

September 24th, 2013 No comments

​If you’re running Java SE 6, we have some news for you: Oracle stopped providing public updates to it after February 2013.

Enterprise customers will still have access to long term help through their support channels.

For everyone else, you should upgrade to Java SE 7 and remove Java SE 6 – remember Java doesn’t remove older versions by default. 

Malware exploiting vulnerabilities in Java isn’t new. We’ve written about Java vulnerabilities on this blog before. In fact, since July this year Exploit:Java/CVE-2013-2465 has been making the rounds and targeting Java SE 6.

Oracle has done a great job of releasing Java updates to patch these vulnerabilities.

However, Java SE 6 is about seven years old, and Java SE 7 was released more than two years ago. This means it’s time to think about alternatives for the aging version.

While we’re talking about end-of-support software – technical assistance for Windows XP will no longer be available from April 8, 2014.

This includes the updates that help protect your PC against security risks and malware. It’s a good time to think about installing Windows 8 on your PC.

 

Categories: Uncategorized Tags:

Get free or paid support for your malware problem

September 24th, 2013 No comments

Is your computer running slowly? Are programs starting unexpectedly? Is the activity light on your broadband or external modem constantly lit? Does it sound like your computer’s hard disk is continually working?

If you answered “yes” to any of these questions, your computer might be infected with malware.

Scan your PC for viruses

If you suspect that your computer has a virus, you can download the Microsoft Safety Scanner. The Microsoft Safety Scanner is a free downloadable security tool that provides on-demand scanning and helps remove viruses, spyware, and other malicious software.

Download the Microsoft Safety Scanner

Get help from the Microsoft forums

If you’ve scanned your computer and you can’t get rid of the virus, you might be able to get free help from the Microsoft Community. Check out the Viruses and Malware forum.

Get help from a Microsoft Answer Tech for $99

If you want to pay for help, a Microsoft Answer Tech can help track down viruses, malware, and spyware.  

Chat with an Answer Tech now

Examining Korea’s Rollercoaster Threat Landscape

September 24th, 2013 No comments

The last time I wrote about the threat landscape in the Republic of Korea, its malware infection rate had increased six-fold in the first six months of 2012. Korea has had one of the most active threat landscapes in the world for many years. According to the latest data published in the Microsoft Security Intelligence Report Volume 14, the last half of 2012 was no different. Figure 1 provides the raw number of systems that were disinfected in Korea and other relatively active locations in each of the four quarters of 2012.  Read more

…(read more)

Upgrade Certification Authority to SHA256

September 19th, 2013 No comments

A common question in the field is about upgrading a certification authority running on Windows Server 2003 to use Crypto Next Generation (CNG) to support SHA256. CNG was introduced in Windows Server 2008 and higher operating systems, as a result,
an upgrade to the operating system is required. After upgrading the certification authority’s operating system, you will need to run
the following commands from an elevated command line window:

 

certutil -setreg cacspCNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

Make sure you are  using a Key Storage Provider that supports SHA256 – for example the Microsoft Key Storage Provider – and then renewing the certification authority’s certificate.

 

If this proves to be too complicated, then you can simply issue certificates to clients using SHA256 even if the entire certification authority’s chain is signed with SHA1 certificates. The applications consuming the SHA256 certificates have to support the SHA256 signature on any given certificate in the chain.

Amer Kamal

Senior Premier Field Engineer

 

Categories: CNG, SHA1, SHA2 Tags:

Upgrade Certification Authority to SHA256

September 19th, 2013 No comments

A common question in the field is about upgrading a certification authority running on Windows Server 2003 to use Crypto Next Generation (CNG) to support SHA256. CNG was introduced in Windows Server 2008 and higher operating systems, as a result,
an upgrade to the operating system is required. After upgrading the certification authority’s operating system, you will need to run
the following commands from an elevated command line window:

 

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

Make sure you are  using a Key Storage Provider that supports SHA256 – for example the Microsoft Key Storage Provider – and then renewing the certification authority’s certificate.

 

If this proves to be too complicated, then you can simply issue certificates to clients using SHA256 even if the entire certification authority’s chain is signed with SHA1 certificates. The applications consuming the SHA256 certificates have to support the SHA256 signature on any given certificate in the chain.

Amer Kamal

Senior Premier Field Engineer

 

Categories: CNG, SHA1, SHA2 Tags:

Upgrade Certification Authority to SHA256

September 19th, 2013 No comments

A common question in the field is about upgrading a certification authority running on Windows Server 2003 to use Crypto Next Generation (CNG) to support SHA256. CNG was introduced in Windows Server 2008 and higher operating systems, as a result,
an upgrade to the operating system is required. After upgrading the certification authority’s operating system, you will need to run
the following commands from an elevated command line window:

 

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

Make sure you are  using a Key Storage Provider that supports SHA256 – for example the Microsoft Key Storage Provider – and then renewing the certification authority’s certificate.

 

If this proves to be too complicated, then you can simply issue certificates to clients using SHA256 even if the entire certification authority’s chain is signed with SHA1 certificates. The applications consuming the SHA256 certificates have to support the SHA256 signature on any given certificate in the chain.

Amer Kamal

Senior Premier Field Engineer

 

Categories: CNG, SHA1, SHA2 Tags:

Help teens prepare for digital drama with new ebook

October is National Cyber Security Awareness Month—a great time to check in with your family about their online safety habits. Are everyone’s devices and apps up to date with the latest security? When was the last time you reviewed your children’s online profile, or helped them update the privacy settings on their social networks?

For teens in particular, it’s important to help them prepare to deal with the “drama” that can unfold within their online social circles. While teen conflict is nothing new, today’s gossip, jokes, and arguments often play out through social media like Formspring, Twitter, and Facebook. Teens often refer to this as “drama.”

We’ve asked Linda McCarthy, online safety expert and author, to share insights about her new digital book, Digital Drama: Staying Safe While Being Social Online.

DOWNLOAD THE BOOK FREE!
From September 24 through 27, you can download English and Spanish versions of the ebook FREE.

Add a calendar reminder

 

 

 

 
Kim Sanchez: You’ve written a number of books about online safety and security for teens. Why the focus on this audience?

Linda McCarthy: In 2009, my two teenagers destroyed the security on my home network; that was a game changer for me. I spent 15 years protecting security networks for corporations, and this happened in my house. At that moment I knew that I had to help families—kids love technology and they need help understanding the risks.

Kim Sanchez: So this was the impetus behind Digital Drama?

Linda McCarthy: Yes. The Internet is a great resource for connecting, learning, and entertainment, but these limitless possibilities also open the door to risky situations. Parents worry about their kids talking to strangers in person—online that risk is 24/7. Also, many parents feel overwhelmed by technology features and functions. Watching the kids in my house grow up on the Internet, and the challenges they (and I) faced, I felt that teens need more information on how to stay safer online.

Kim Sanchez: What are you hearing from kids about the ebook?

Linda McCarthy: The response has been great, which excites me because this is my first digital book. I’ve been writing and publishing security books for 20 years, and I love to hold a solid book in my hands, so I wasn’t sold on the ebook idea. However, teens prefer to read online and we have to be able to give kids what they want, right?

Kim Sanchez: What is an important tip you’d give teens to help them deal with digital drama?

Linda McCarthy: Know when to walk away, when NOT to respond, and when to get help.

  • Know when to walk away. When your friends start documenting their stupidity online, don’t hang around and become the star in their pictures or videos. Anything that’s posted online can stay around forever.
  • Know when NOT to respond. If “friends” start sending you bullying text messages, don’t get pulled into their drama by responding. Bullying can be a crime depending on what the bullies are doing.
  • Know when to get help. When drama is about to turn lethal or bullying is happening, reach out to a trusted adult for help. You can do it anonymously so you don’t become the next victim of the bully, and reaching out might just help someone else, too.

Kim Sanchez: How about a tip for parents that would help teens deal with digital drama?

Linda McCarthy: The most important thing I can say to parents is don’t just hand your child a new device, like a smart phone or tablet, and that’s it. Instead, set up some rules of the road together.

For example, guidelines for using a phone might include no bullying or teasing others, no texting and driving, share location cautiously, and create a positive online profile (don’t share scandalous photos). Then if drama unfolds, you can refer back to the family agreement, which might help minimize the extent of the drama.

Kim Sanchez: Your book was written for teens. Would it be useful for anyone else?

Linda McCarthy: Digital Drama has something for everyone. Parents can read it and get ideas about how to talk with their kids about online safety. Even if you don’t have kids, you’ll find guidance that will help you, a family member, or a friend. So download the ebook and share it with everyone you know.

Kim Sanchez: You’ve devoted an entire chapter to online bullying, or “cyberbullying.” Why is that?

Linda McCarthy: According to Microsoft research, 62 percent of teens have witnessed cruel behavior online. Just about every teen I talk to either knows someone who has been bullied, or has been bullied themselves. So, I’ve given ten pointers to help teens protect themselves and their friends from cyberbullying—starting with reporting it. I’m also publishing a book for parents about cyberbullying this fall: Cyberbully Upstander: My Child Is Safe. Parents need to talk with kids about bullying and why it’s important to reach out and get help when first witnessing it.

Join the Twitter conversation!

Join Microsoft and other online safety experts on September 25 at 3:00 p.m. EDT/12:00 p.m. PDT as we chat with Linda McCarthy (@ddramabook) about how her ebook can help you talk with kids about digital safety. (Use #ChatSTC to join.)

ISA 2006 / TMG 2010: DISABLE CLIENT-INITIATED SSL RENEGOTIATION, PROTECTING AGAINST DOS ATTACKS AND MALICIOUS DATA INJECTION

September 18th, 2013 No comments

In these days we received a considerable number of support requests asking for more info about SSL/TLS Renegotiation and the risk it introduces of being exposed to DoS attacks and malicious code injections.

The requests in object were focused on ISA/TMG products, considering they are used as reverse proxy for web publishing purposes, but the below considerations can be considered valid for every kind of Windows server/client supporting SSL/TLS connections.

First, what is exactly SSL/TLS Renegotiation?

"TLS [as defined in RFC 5246] allows either the client or the server to initiate a renegotiation — a new handshake that establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client’s transport layer connection can inject traffic of his own as a prefix to the client’s interaction with the server"

The above definition is taken from RFC 5746.

The following is a graphic representation of a basic SSL/TLS Handshake:

clip_image002

 

 

 

 

 

 

 

 

 

 

Under certain circumstances, the client could be asking the server a renegotiation of the SSL/TLS parameters using the same TCP socket:

clip_image004

If the SSL/TLS is not secure (as per RFC 5746 recommendations) a MITM could use the renegotiation to send the server malicious data, pretending to be "good" user.

clip_image006

What chances do we have to mitigate this issue?

You should make sure, that the following security hotfix is installed:

http://support.microsoft.com/kb/980436

This fix is making the system compliant with RFC 5746, mitigating the risk of malicious data injection.

To provide backward compatibility, this security update works in the following modes: STRICT and COMPATIBLE

Compatible mode

o If this security update is applied to the server, and the server is in compatible mode, the server allows all clients to set up and renegotiate Transport Layer Security (TLS) sessions. This occurs whether the clients are updated or are not updated by using this security update.

o Similarly, if this security update is applied to the client, and the client is in compatible mode, the client can set up and renegotiate TLS sessions with all the servers for which this security update is applied or is not applied.

Strict mode

o If this security update is applied to the server, and the server is in strict mode, the server allows only those clients to which this security update is applied to set up and renegotiate TLS sessions. The server does not allow the clients to which this security update is not applied to set up the TLS session. In this case, the server terminates such requests from the clients.

Similarly, if this security update is applied to the client, and the client is in strict mode, the client can set up and renegotiate TLS sessions with all the servers for which this security update is applied. The clients cannot set up TLS sessions at all with servers for which this security update is not applied. The client cannot move ahead with a TLS negotiation attempt with such servers.

By default, this security update enables the TLS or Secure Sockets Layer (SSL) client or server to stay in compatible mode. An administrator can use the AllowInsecureRenegoClients and the AllowInsecureRenegoServers entry DWORD values in the following registry path to enable strict mode on the client or on the server:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersSCHANNEL

The following table shows how these DWORD values can be used:

DWORD

Value = zero

Value = nonzero

AllowInsecureRenegoClients

Strict Server

Compatible Server

AllowInsecureRenegoServers

Strict Client

Compatible Client

Malicious data injection is not the only problem related to Renegotiation: it can be in fact used to perform DoS attacks against a server.

When a new SSL/TLS connection is being negotiated, the server will typically spend significantly more CPU resources than the client. A malicious user, leveraging the Renegotiation, could be able to enhance the server’s CPU usage causing DoS.

In order to have a better mitigation for both malicious data injection and DoS attacks, the best option would be to reject the client-initiated SSL/TLS renegotiation at all.

The following Microsoft Security Advisory explains how:

http://support.microsoft.com/kb/977377/en-us

As reported in the article, the behavior can be modified by changing the value of the following registry key:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersSCHANNELDisableRenegoOnServer

Notes

· If the DisableRenegoOnClient subkey is present and has any nonzero value:

o The client will not initiate renegotiation.

o The client will not respond to renegotiation.

· If the DisableRenegoOnClient subkey is missing or is present and has a zero value:

o The client will initiate renegotiation.

o The client will respond to renegotiation.

· If the DisableRenegoOnServer subkey is present and has any nonzero value:

o Server initiated renegotiation is not allowed.

o The server will not respond to renegotiation requests from the client.

· If the DisableRenegoOnServer subkey is missing or is present and has a zero value:

o Server initiated renegotiation is allowed.

o The server will respond to renegotiation requests from the client.

Of course, this may have an impact on the use of specific applications requiring SSL/TLS renegotiation feature.

The KB article underlines the following:

o After you install this security update, you cannot use the legacy provisioning service parameter (–UseLegacyProvisioningService) when you create a federation trust with the Microsoft Federation Gateway. The security update will prevent the federation trust from working correctly. This problem will occur if you install this security update on a computer that is running Exchange Server 2010 or Exchange Server 2010 Service Pack 1 before you have created a federation trust. To avoid this problem, you must create the federation trust before you install this security update. 
For more information about how to create a federation trust by using the –UseLegacyProvisioningService parameter, visit the following Microsoft webpage:
Create a Federation Trust

o When you install this update on a computer that has the Microsoft Online Single Sign-In services client installed, you may experience the following issues:

· The Sign In client cannot obtain user configuration information. This only affects new users who are running the Sign In client for the first time. The Sign In client cannot obtain information to configure Outlook. If the Sign In client has already run and configured the applications, there are no additional issues with the Sign In client.

· Outlook users cannot see free/busy information. Therefore, this update also affects existing Outlook users.
To resolve this problem, set the DisableRenegoOnClient registry entry to a value of 0 (zero), and then restart the computer.

o This update disables TLS/SSL renegotiation, common protocol functionality that is required for specific applications. This may cause this software to no longer function as expected. If any side effects are experienced, customers should uninstall the workaround to resolve the issue.
The following software has been tested by Microsoft and that has been found to experience problems when you install this update:

· Windows 7 DirectAccess: The IP HTTPS interface will not function.

· Exchange ActiveSync: Does not function when it uses certificate client authentication.

· Internet Information Services (IIS): In certain configurations, IIS using certificate client authentication, including certificate mapping scenarios, will be affected. Site-wide client certificate authentication will not be affected and will continue to function.

· Internet Explorer: When you browse Web sites that require client certificate authentication, but not site-wide client certificate authentication, you may not successfully be able to connect.

Of course, it’s not possible to predict the implications of disabling client-initiated renegotiation for various applications: this solution should be appropriately tested in each specific environment.

From a security point of view, though, this is the recommended way to mitigate all the above described problems.

Hope this can help!

 

Author: 

Daniele Gaiulli

Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand

Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: https tls, secure, Security Update Tags:

ISA 2006 / TMG 2010: DISABLE CLIENT-INITIATED SSL RENEGOTIATION, PROTECTING AGAINST DOS ATTACKS AND MALICIOUS DATA INJECTION

September 18th, 2013 No comments

In these days we received a considerable number of support requests asking for more info about SSL/TLS Renegotiation and the risk it introduces of being exposed to DoS attacks and malicious code injections.

The requests in object were focused on ISA/TMG products, considering they are used as reverse proxy for web publishing purposes, but the below considerations can be considered valid for every kind of Windows server/client supporting SSL/TLS connections.

First, what is exactly SSL/TLS Renegotiation?

"TLS [as defined in RFC 5246] allows either the client or the server to initiate a renegotiation — a new handshake that establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client’s transport layer connection can inject traffic of his own as a prefix to the client’s interaction with the server"

The above definition is taken from RFC 5746.

The following is a graphic representation of a basic SSL/TLS Handshake:

clip_image002

 

 

 

 

 

 

 

 

 

 

Under certain circumstances, the client could be asking the server a renegotiation of the SSL/TLS parameters using the same TCP socket:

clip_image004

If the SSL/TLS is not secure (as per RFC 5746 recommendations) a MITM could use the renegotiation to send the server malicious data, pretending to be "good" user.

clip_image006

What chances do we have to mitigate this issue?

You should make sure, that the following security hotfix is installed:

http://support.microsoft.com/kb/980436

This fix is making the system compliant with RFC 5746, mitigating the risk of malicious data injection.

To provide backward compatibility, this security update works in the following modes: STRICT and COMPATIBLE

Compatible mode

o If this security update is applied to the server, and the server is in compatible mode, the server allows all clients to set up and renegotiate Transport Layer Security (TLS) sessions. This occurs whether the clients are updated or are not updated by using this security update.

o Similarly, if this security update is applied to the client, and the client is in compatible mode, the client can set up and renegotiate TLS sessions with all the servers for which this security update is applied or is not applied.

Strict mode

o If this security update is applied to the server, and the server is in strict mode, the server allows only those clients to which this security update is applied to set up and renegotiate TLS sessions. The server does not allow the clients to which this security update is not applied to set up the TLS session. In this case, the server terminates such requests from the clients.

Similarly, if this security update is applied to the client, and the client is in strict mode, the client can set up and renegotiate TLS sessions with all the servers for which this security update is applied. The clients cannot set up TLS sessions at all with servers for which this security update is not applied. The client cannot move ahead with a TLS negotiation attempt with such servers.

By default, this security update enables the TLS or Secure Sockets Layer (SSL) client or server to stay in compatible mode. An administrator can use the AllowInsecureRenegoClients and the AllowInsecureRenegoServers entry DWORD values in the following registry path to enable strict mode on the client or on the server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL

The following table shows how these DWORD values can be used:

DWORD

Value = zero

Value = nonzero

AllowInsecureRenegoClients

Strict Server

Compatible Server

AllowInsecureRenegoServers

Strict Client

Compatible Client

Malicious data injection is not the only problem related to Renegotiation: it can be in fact used to perform DoS attacks against a server.

When a new SSL/TLS connection is being negotiated, the server will typically spend significantly more CPU resources than the client. A malicious user, leveraging the Renegotiation, could be able to enhance the server’s CPU usage causing DoS.

In order to have a better mitigation for both malicious data injection and DoS attacks, the best option would be to reject the client-initiated SSL/TLS renegotiation at all.

The following Microsoft Security Advisory explains how:

http://support.microsoft.com/kb/977377/en-us

As reported in the article, the behavior can be modified by changing the value of the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\DisableRenegoOnServer

Notes

· If the DisableRenegoOnClient subkey is present and has any nonzero value:

o The client will not initiate renegotiation.

o The client will not respond to renegotiation.

· If the DisableRenegoOnClient subkey is missing or is present and has a zero value:

o The client will initiate renegotiation.

o The client will respond to renegotiation.

· If the DisableRenegoOnServer subkey is present and has any nonzero value:

o Server initiated renegotiation is not allowed.

o The server will not respond to renegotiation requests from the client.

· If the DisableRenegoOnServer subkey is missing or is present and has a zero value:

o Server initiated renegotiation is allowed.

o The server will respond to renegotiation requests from the client.

Of course, this may have an impact on the use of specific applications requiring SSL/TLS renegotiation feature.

The KB article underlines the following:

o After you install this security update, you cannot use the legacy provisioning service parameter (–UseLegacyProvisioningService) when you create a federation trust with the Microsoft Federation Gateway. The security update will prevent the federation trust from working correctly. This problem will occur if you install this security update on a computer that is running Exchange Server 2010 or Exchange Server 2010 Service Pack 1 before you have created a federation trust. To avoid this problem, you must create the federation trust before you install this security update. 
For more information about how to create a federation trust by using the –UseLegacyProvisioningService parameter, visit the following Microsoft webpage:
Create a Federation Trust

o When you install this update on a computer that has the Microsoft Online Single Sign-In services client installed, you may experience the following issues:

· The Sign In client cannot obtain user configuration information. This only affects new users who are running the Sign In client for the first time. The Sign In client cannot obtain information to configure Outlook. If the Sign In client has already run and configured the applications, there are no additional issues with the Sign In client.

· Outlook users cannot see free/busy information. Therefore, this update also affects existing Outlook users.
To resolve this problem, set the DisableRenegoOnClient registry entry to a value of 0 (zero), and then restart the computer.

o This update disables TLS/SSL renegotiation, common protocol functionality that is required for specific applications. This may cause this software to no longer function as expected. If any side effects are experienced, customers should uninstall the workaround to resolve the issue.
The following software has been tested by Microsoft and that has been found to experience problems when you install this update:

· Windows 7 DirectAccess: The IP HTTPS interface will not function.

· Exchange ActiveSync: Does not function when it uses certificate client authentication.

· Internet Information Services (IIS): In certain configurations, IIS using certificate client authentication, including certificate mapping scenarios, will be affected. Site-wide client certificate authentication will not be affected and will continue to function.

· Internet Explorer: When you browse Web sites that require client certificate authentication, but not site-wide client certificate authentication, you may not successfully be able to connect.

Of course, it’s not possible to predict the implications of disabling client-initiated renegotiation for various applications: this solution should be appropriately tested in each specific environment.

From a security point of view, though, this is the recommended way to mitigate all the above described problems.

Hope this can help!

 

Author: 

Daniele Gaiulli

Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand

Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: https tls, secure, Security Update Tags:

ISA 2006 / TMG 2010: DISABLE CLIENT-INITIATED SSL RENEGOTIATION, PROTECTING AGAINST DOS ATTACKS AND MALICIOUS DATA INJECTION

September 18th, 2013 No comments

In these days we received a considerable number of support requests asking for more info about SSL/TLS Renegotiation and the risk it introduces of being exposed to DoS attacks and malicious code injections.

The requests in object were focused on ISA/TMG products, considering they are used as reverse proxy for web publishing purposes, but the below considerations can be considered valid for every kind of Windows server/client supporting SSL/TLS connections.

First, what is exactly SSL/TLS Renegotiation?

"TLS [as defined in RFC 5246] allows either the client or the server to initiate a renegotiation — a new handshake that establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client’s transport layer connection can inject traffic of his own as a prefix to the client’s interaction with the server"

The above definition is taken from RFC 5746.

The following is a graphic representation of a basic SSL/TLS Handshake:

clip_image002

 

 

 

 

 

 

 

 

 

 

Under certain circumstances, the client could be asking the server a renegotiation of the SSL/TLS parameters using the same TCP socket:

clip_image004

If the SSL/TLS is not secure (as per RFC 5746 recommendations) a MITM could use the renegotiation to send the server malicious data, pretending to be "good" user.

clip_image006

What chances do we have to mitigate this issue?

You should make sure, that the following security hotfix is installed:

http://support.microsoft.com/kb/980436

This fix is making the system compliant with RFC 5746, mitigating the risk of malicious data injection.

To provide backward compatibility, this security update works in the following modes: STRICT and COMPATIBLE

Compatible mode

o If this security update is applied to the server, and the server is in compatible mode, the server allows all clients to set up and renegotiate Transport Layer Security (TLS) sessions. This occurs whether the clients are updated or are not updated by using this security update.

o Similarly, if this security update is applied to the client, and the client is in compatible mode, the client can set up and renegotiate TLS sessions with all the servers for which this security update is applied or is not applied.

Strict mode

o If this security update is applied to the server, and the server is in strict mode, the server allows only those clients to which this security update is applied to set up and renegotiate TLS sessions. The server does not allow the clients to which this security update is not applied to set up the TLS session. In this case, the server terminates such requests from the clients.

Similarly, if this security update is applied to the client, and the client is in strict mode, the client can set up and renegotiate TLS sessions with all the servers for which this security update is applied. The clients cannot set up TLS sessions at all with servers for which this security update is not applied. The client cannot move ahead with a TLS negotiation attempt with such servers.

By default, this security update enables the TLS or Secure Sockets Layer (SSL) client or server to stay in compatible mode. An administrator can use the AllowInsecureRenegoClients and the AllowInsecureRenegoServers entry DWORD values in the following registry path to enable strict mode on the client or on the server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL

The following table shows how these DWORD values can be used:

DWORD

Value = zero

Value = nonzero

AllowInsecureRenegoClients

Strict Server

Compatible Server

AllowInsecureRenegoServers

Strict Client

Compatible Client

Malicious data injection is not the only problem related to Renegotiation: it can be in fact used to perform DoS attacks against a server.

When a new SSL/TLS connection is being negotiated, the server will typically spend significantly more CPU resources than the client. A malicious user, leveraging the Renegotiation, could be able to enhance the server’s CPU usage causing DoS.

In order to have a better mitigation for both malicious data injection and DoS attacks, the best option would be to reject the client-initiated SSL/TLS renegotiation at all.

The following Microsoft Security Advisory explains how:

http://support.microsoft.com/kb/977377/en-us

As reported in the article, the behavior can be modified by changing the value of the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\DisableRenegoOnServer

Notes

· If the DisableRenegoOnClient subkey is present and has any nonzero value:

o The client will not initiate renegotiation.

o The client will not respond to renegotiation.

· If the DisableRenegoOnClient subkey is missing or is present and has a zero value:

o The client will initiate renegotiation.

o The client will respond to renegotiation.

· If the DisableRenegoOnServer subkey is present and has any nonzero value:

o Server initiated renegotiation is not allowed.

o The server will not respond to renegotiation requests from the client.

· If the DisableRenegoOnServer subkey is missing or is present and has a zero value:

o Server initiated renegotiation is allowed.

o The server will respond to renegotiation requests from the client.

Of course, this may have an impact on the use of specific applications requiring SSL/TLS renegotiation feature.

The KB article underlines the following:

o After you install this security update, you cannot use the legacy provisioning service parameter (–UseLegacyProvisioningService) when you create a federation trust with the Microsoft Federation Gateway. The security update will prevent the federation trust from working correctly. This problem will occur if you install this security update on a computer that is running Exchange Server 2010 or Exchange Server 2010 Service Pack 1 before you have created a federation trust. To avoid this problem, you must create the federation trust before you install this security update. 
For more information about how to create a federation trust by using the –UseLegacyProvisioningService parameter, visit the following Microsoft webpage:
Create a Federation Trust

o When you install this update on a computer that has the Microsoft Online Single Sign-In services client installed, you may experience the following issues:

· The Sign In client cannot obtain user configuration information. This only affects new users who are running the Sign In client for the first time. The Sign In client cannot obtain information to configure Outlook. If the Sign In client has already run and configured the applications, there are no additional issues with the Sign In client.

· Outlook users cannot see free/busy information. Therefore, this update also affects existing Outlook users.
To resolve this problem, set the DisableRenegoOnClient registry entry to a value of 0 (zero), and then restart the computer.

o This update disables TLS/SSL renegotiation, common protocol functionality that is required for specific applications. This may cause this software to no longer function as expected. If any side effects are experienced, customers should uninstall the workaround to resolve the issue.
The following software has been tested by Microsoft and that has been found to experience problems when you install this update:

· Windows 7 DirectAccess: The IP HTTPS interface will not function.

· Exchange ActiveSync: Does not function when it uses certificate client authentication.

· Internet Information Services (IIS): In certain configurations, IIS using certificate client authentication, including certificate mapping scenarios, will be affected. Site-wide client certificate authentication will not be affected and will continue to function.

· Internet Explorer: When you browse Web sites that require client certificate authentication, but not site-wide client certificate authentication, you may not successfully be able to connect.

Of course, it’s not possible to predict the implications of disabling client-initiated renegotiation for various applications: this solution should be appropriately tested in each specific environment.

From a security point of view, though, this is the recommended way to mitigate all the above described problems.

Hope this can help!

 

Author: 

Daniele Gaiulli

Support Engineer – Microsoft Forefront Edge Security Team

Reviewer:

Philipp Sand

Sr. Support Escalation Engineer – Microsoft Forefront Edge Security Team

Categories: https tls, secure, Security Update Tags:

MS13-023 – Critical : Vulnerability in Microsoft Visio Viewer 2010 Could Allow Remote Code Execution (2801261) – Version: 1.2

Severity Rating: Critical
Revision Note: V1.2 (September 18, 2013): Corrected language in the vulnerability FAQ, How could an attacker exploit the vulnerability? This is an informational change only.
Summary: This security update resolves a privately reported vulnerability in Microsoft Office. The vulnerability could allow remote code execution if a user opens a specially crafted Visio file. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Categories: Uncategorized Tags:

Microsoft Releases Security Advisory 2887505

September 17th, 2013 No comments

Today we released Security Advisory 2887505 regarding an issue that affects Internet Explorer. There are only reports of a limited number of targeted attacks specifically directed at Internet Explorer 8 and 9, although the issue could potentially affect all supported versions. This issue could allow remote code execution if an affected system browses to a website containing malicious content directed towards the specific browser type. This would typically occur when an attacker compromises the security of trusted websites regularly frequented, or convinces someone to click on a link in an email or instant message. Running modern versions of Internet Explorer ensures that customers receive the benefit of additional security features that can help prevent successful attacks.

While we are actively working to develop a security update to address this issue, we encourage Internet Explorer customers concerned with the risk associated with this vulnerability, to deploy the following workarounds and mitigations from the advisory:

  • Apply the Microsoft Fix it solution, “CVE-2013-3893 MSHTML Shim Workaround,” that prevents exploitation of this issue
    See Microsoft Knowledge Base Article 2887505 to use the automated Microsoft Fix it solution to enable or disable this workaround.
  • Set Internet and local intranet security zone settings to “High” to block ActiveX Controls and Active Scripting in these zones
    This will help prevent exploitation but may affect usability; therefore, trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and local intranet security zones
    This will help prevent exploitation but can affect usability, so trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.

As a best practice, we always encourage customers to follow the “Protect Your Computer” guidance of enabling a firewall, applying all software updates and installing anti-virus and anti-spyware software. We also encourage customers to exercise caution when visiting websites and avoid clicking suspicious links or opening email messages from unfamiliar senders. Additional information can be found at www.microsoft.com/protect.

We are monitoring the threat landscape very closely and will continue to take appropriate action to help protect our customers.

Thank you,

Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

Microsoft Releases Security Advisory 2887505

September 17th, 2013 No comments

Today we released Security Advisory 2887505 regarding an issue that affects Internet Explorer. There are only reports of a limited number of targeted attacks specifically directed at Internet Explorer 8 and 9, although the issue could potentially affect all supported versions. This issue could allow remote code execution if an affected system browses to a website containing malicious content directed towards the specific browser type. This would typically occur when an attacker compromises the security of trusted websites regularly frequented, or convinces someone to click on a link in an email or instant message. Running modern versions of Internet Explorer ensures that customers receive the benefit of additional security features that can help prevent successful attacks.

While we are actively working to develop a security update to address this issue, we encourage Internet Explorer customers concerned with the risk associated with this vulnerability, to deploy the following workarounds and mitigations from the advisory:

  • Apply the Microsoft Fix it solution, “CVE-2013-3893 MSHTML Shim Workaround,” that prevents exploitation of this issue
    See Microsoft Knowledge Base Article 2887505 to use the automated Microsoft Fix it solution to enable or disable this workaround.
  • Set Internet and local intranet security zone settings to “High” to block ActiveX Controls and Active Scripting in these zones
    This will help prevent exploitation but may affect usability; therefore, trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and local intranet security zones
    This will help prevent exploitation but can affect usability, so trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.

As a best practice, we always encourage customers to follow the “Protect Your Computer” guidance of enabling a firewall, applying all software updates and installing anti-virus and anti-spyware software. We also encourage customers to exercise caution when visiting websites and avoid clicking suspicious links or opening email messages from unfamiliar senders. Additional information can be found at www.microsoft.com/protect.

We are monitoring the threat landscape very closely and will continue to take appropriate action to help protect our customers.

Thank you,

Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

Download fix for Internet Explorer vulnerability

September 17th, 2013 No comments

We’ve confirmed that cybercriminals are currently targeting a limited number of Internet Explorer customers through trusted websites.

If you’re not running a modern version of Internet Explorer, we recommend upgrading immediately to ensure that you receive the benefit of additional security features that can help prevent successful attacks. We also recommend installing the newly released Fix it (an easy, one-click download to help keep your computer protected), which does not require a reboot. Not sure if you are running a modern version of Internet Explorer? Learn how to check your web browser version

To find tips on how to stay safer online, visit the Microsoft Safety & Security Center.

Addendum: This Fix it was designed for all versions of Internet Explorer. If you have automatic updating turned on, you already received this update as part of our normal updating process on Security Update Tuesday, October 8.

 Learn more about how to get security updates automatically.

Categories: Fix it, Internet Explorer, malware Tags: