Archive

Archive for September, 2014

MS14-049 – Important: Vulnerability in Windows Installer Service Could Allow Elevation of Privilege (2962490) – Version: 1.2

Severity Rating: Important
Revision Note: V1.2 (September 24, 2014): Bulletin revised to change Known issues entry in the Knowledge Base Article section from None to Yes.
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.

Categories: Uncategorized Tags:

MS14-FEB – Microsoft Security Bulletin Summary for February 2014 – Version: 1.3

Revision Note: V1.3 (September 24, 2014): For MS14-009, added a missing Server Core entry in the Affected Software table for Microsoft .NET Framework 4 when installed on Windows Server 2008 R2 for x64-based Systems Service Pack 1 (2898855). This is an informational change only. Customers running this affected software on Server Core installations who have already applied the 2898855 update do not need to take any action. Customers running this affected software on Server Core installations who have not already installed the update should do so to be protected from the vulnerabilities addressed in MS14-009. See the bulletin for download links.
Summary: This bulletin summary lists security bulletins released for February 2014.

Categories: Uncategorized Tags:

MS14-009 – Important: Vulnerabilities in .NET Framework Could Allow Elevation of Privilege – Version: 1.3

Severity Rating: Important
Revision Note: V1.3 (September 24, 2014): Bulletin revised to correct a missing Server Core installation entry in the Affected Software table for Microsoft .NET Framework 4 when installed on Windows Server 2008 R2 for x64-based Systems Service Pack 1 (2898855). This is an informational change only. Customers running this affected software on Server Core installations who have already applied the 2898855 update do not need to take any action. Customers running this affected software on Server Core installations who have not already installed the update should do so to be protected from the vulnerabilities addressed in this bulletin.
Summary: This security update resolves two publicly disclosed vulnerabilities and one privately reported vulnerability in Microsoft .NET Framework. The most severe vulnerability could allow elevation of privilege if a user visits a specially crafted website or a website containing specially crafted web content. In all cases, however, an attacker would have no way to force users to visit such websites. Instead, an attacker would have to convince users to visit the compromised website, typically by getting them to click a link in an email message or in an Instant Messenger message that takes them to the attacker’s website.

Categories: Uncategorized Tags:

MS14-055 – Important: Vulnerabilities in Microsoft Lync Server Could Allow Denial of Service (2990928) – Version: 3.0

Severity Rating: Important
Revision Note: V3.0 (September 23, 2014): Bulletin rereleased to announce the reoffering of the 2982385 security update file (server.msp) for Microsoft Lync Server 2010. See the Update FAQ for details.
Summary: This security update resolves three privately reported vulnerabilities in Microsoft Lync Server. The most severe of these vulnerabilities could allow information disclosure if user clicks on a specially crafted URL. In all cases, however, an attacker would have to convince users to click on the specially crafted URL, typically by getting them to click the URL in an email message or in an Instant Messenger request.

Categories: Uncategorized Tags:

2755801 – Update for Vulnerabilities in Adobe Flash Player in Internet Explorer – Version: 29.0

Revision Note: V29.0 (September 23, 2014): Added the 2999249 update to the Current Update section.
Summary: Microsoft is announcing the availability of an update for Adobe Flash Player in Internet Explorer on all supported editions of Windows 8, Windows Server 2012, Windows RT, Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1. The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10 and Internet Explorer 11.

Categories: Uncategorized Tags:

Microsoft cloud protection

September 22nd, 2014 No comments

​Microsoft is using cloud protection to help keep our customers safe. In fact, nearly any detection made by Microsoft security products could be the result of cloud protection. Software developers often ask us how this cloud protection works and how they can improve our cloud’s impression of their software.

How our cloud protection works

When our antimalware products encounter anything unusual, they can send a small packet of information about the event or file to our server. The server then sends back a reply telling the antimalware software whether to block it or not. It can also request a sample for further analysis.

There are three situations that highlight the benefits of cloud protection:

  • If a file is known to be malware by our servers but not by the local antimalware product, the cloud protection module can tell the local product to block or remove it.
  • If a file is known to be clean by our servers, but the local antimalware product detects the file as malware (an incorrect detection situation), the cloud protection module can tell the local antimalware to not detect it, and the incorrect detection does not affect the user.
  • If a local antimalware product encounters a file that we don’t know about, our server can make a determination based on probabilities, and tell the local antimalware software to block it, even without having seen a copy of the file.

It’s this third point that I would like to discuss further.

Improving your software’s cloud impression

We are often asked by software vendors if we have a way for them to pre-whitelist their software. However, our backend processing actually works better if we see your software as it’s naturally distributed. I will outline a few methods to improve our cloud’s impression of your software below:

  • Digitally sign your software using a method accepted by Microsoft. This is the fastest way to get a good cloud reputation because the reputation of a good file can be distributed to all files signed by the same key.
  • Once you have digitally signed your software, be careful that malware isn’t also signed by your key. This will negate any good reputation. You can help avoid this situation by:
    • Making sure you protect your key from being stolen by malware authors.
    • Ensuring your development process prevents a parasitic file-infecting virus from being inadvertently signed by your key.
    • Reading more about the best practices for signing software.

  • If you can’t digitally sign your software, be aware that every minor version of your product will have to build reputation from scratch. This affects vendors who provide a different file on every single download. It doesn’t mean you can’t make bug-fix versions, different languages, etc.
  • Make sure your software doesn’t install malware:
    • Take care to avoid security vulnerabilities. Even if you don’t intend to install malware, a security vulnerability could be detected as your product installing malware.
    • If you download executables off the internet, have your software check a digital signature or cryptographic hash, to ensure it has the correct file you intended it to download. We have seen one case where a popular installer had some URLs distributing malware and we had to detect every one of their installers in case it was downloading one of the malware URLs.
  • Make sure your software isn’t installed by malware:
    • Proactively check your affiliates and companies who bundle your software.
    • Fill out the metadata information such as the information about the author and company in the file resources. If this and the digital signature isn’t enough, consider adding contact information, or a pointer to find contact information on the web. This contact information should direct to the right contact to report a security vulnerability, or work with to fix or prevent a incorrect detection.
  • If you use a runtime packer or obfuscator, you need to be aware that the majority of malware is packed or obfuscated, and this does affect how your software is seen at the back end.
  • Consider how your software is seen and whether it’s installed on the machines of users who really want it. We have honeypots, web crawlers, and automatic software testing. We can look at whether users chose to continue the download after the warning that a program isn’t commonly downloaded. We can also see whether users chose to ignore or remove software if our antimalware detects it. Bad behavior can quickly ruin a good software reputation.
  • There are some behaviors that, while not enough to warrant a detection on their own, do attract the suspicion of human and automated systems. They could be used for legitimate reasons, but are often closely associated with malware behavior. This includes:
    • Installing outside the commonly accepted folders for the type of software.
    • Modifying or adding a sensitive registry key.
    • Process or thread injection.
    • Autonomous internet activity.

If you believe we have made an incorrect detection for your product you can submit a developer contact form. Making a slight change and pushing it out to your software won’t necessarily address any incorrect bad reputation applied to the code signing key you used for the file that was incorrectly detected. Our cloud protection might also note the similarity between the file that it still believes was correctly detected as malware, and the new version.

MMPC

Categories: cloud protection Tags:

MS14-046 – Important: Vulnerability in .NET Framework Could Allow Security Feature Bypass (2984625) – Version: 1.2

Severity Rating: Important
Revision Note: V1.2 (September 19, 2014): Updated the Known Issues entry in the Knowledge Base Article section from “None” to “Yes”.
Summary: This security update resolves a privately reported vulnerability in Microsoft .NET Framework. The vulnerability could allow security feature bypass if a user visits a specially crafted website. In a web-browsing attack scenario, an attacker who successfully exploited this vulnerability could bypass the Address Space Layout Randomization (ASLR) security feature, which helps protect users from a broad class of vulnerabilities. The security feature bypass by itself does not allow arbitrary code execution. However, an attacker could use this ASLR bypass vulnerability in conjunction with another vulnerability, such as a remote code execution vulnerability, that could take advantage of the ASLR bypass to run arbitrary code.

Categories: Uncategorized Tags:

HOW TO: Report the Microsoft phone scam

September 18th, 2014 No comments

If someone calls you from Microsoft technical support and offers to help you fix your computer, mobile phone, or tablet, this is a scam designed to install malicious software on your computer, steal your personal information, or both.

Do not trust unsolicited calls. Do not provide any personal information.

You can report this scam to the following authorities:

Whenever you receive a phone call or see a pop-up window on your PC and feel uncertain whether it is from someone at Microsoft, don’t take the risk. Reach out directly to one of our technical support experts dedicated to helping you at the Microsoft Answer Desk. Or you can simply call us at 1-800-426-9400 or one of our customer service phone numbers for people located around the world. 

HOW TO: Report the Microsoft phone scam

September 18th, 2014 No comments

If someone calls you from Microsoft technical support and offers to help you fix your computer, mobile phone, or tablet, this is a scam designed to install malicious software on your computer, steal your personal information, or both.

Do not trust unsolicited calls. Do not provide any personal information.

You can report this scam to the following authorities:

Whenever you receive a phone call or see a pop-up window on your PC and feel uncertain whether it is from someone at Microsoft, don’t take the risk. Reach out directly to one of our technical support experts dedicated to helping you at the Microsoft Answer Desk. Or you can simply call us at 1-800-426-9400 or one of our customer service phone numbers for people located around the world.

Missing BDA hook rules – impact and potential root cause

September 18th, 2014 No comments

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

clip_image001

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

clip_image002

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

clip_image003

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Categories: NLB, TMG Tags:

Missing BDA hook rules – impact and potential root cause

September 18th, 2014 No comments

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

clip_image001

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

clip_image002

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

clip_image003

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Categories: NLB, TMG Tags:

MS14-012 – Critical: Cumulative Security Update for Internet Explorer (2925418) – Version: 1.1

Severity Rating: Critical
Revision Note: V1.1 (September 18, 2014): Corrected the severity table and vulnerability information to add CVE-2014-4112 as a vulnerability addressed by this update. This is an informational change only. Customers who have already successfully installed the update do not have to take any action.
Summary: This security update resolves one publicly disclosed vulnerability and seventeen privately reported vulnerabilities in Internet Explorer. These vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited these vulnerabilities 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:

MS14-MAR – Microsoft Security Bulletin Summary for March 2014 – Version: 1.1

Revision Note: V1.1 (September 18, 2014): For MS14-012, added an Exploitability Assessment in the Exploitability Index for CVE-2014-4112. This is an informational change only.
Summary: This bulletin summary lists security bulletins released for March 2014.

Categories: Uncategorized Tags:

Missing BDA hook rules – impact and potential root cause

September 18th, 2014 No comments

Some of you may have already heard and know what NLB is and how it works as described in the general Network Load Balancing Overview [http://technet.microsoft.com/en-us/library/cc725946.aspx].

An integral part of a TMG NLB solution is Bi-direction affinity, which is well described at the following link:

Bi-Directional Affinity in ISA Server [http://blogs.technet.com/b/isablog/archive/2008/03/12/bi-directional-affinity-in-isa-server.aspx].

Bi-directional affinity creates multiple instances of Network Load Balancing (NLB) on the same host, which work in tandem to ensure that responses from published servers are routed through the appropriate ISA servers in a cluster. Bi-directional affinity is commonly used when NLB is configured with Internet Security and Acceleration (ISA) servers. If bi-directional affinity is not consistent across all NLB hosts or if NLB fails to initialize bi-directional affinity, the NLB cluster will remain in the converging state until a consistent teaming configuration is detected.

Bi-directional affinity is a crucial thing if you enable NLB on multiple interfaces, as it ensures a single client to work through the same node and have consistent data flow.

By default when a client connects to an NLB interface a hash algorithm based on the packet source IP (client) is computed in the NLB driver to decide which NLB node should handle this request. On the way back (the server responses to the client) the source IP is the server IP (not the client IP) and without BDA it may be handled by another TMG NLB node – which would discard the server response, not having seen the client request. Hence, a mechanism is needed to guarantee that client/server packets are handled by the same host in the array.

Bidirectional affinity ensures the server responses are handled by the same TMG NLB node as the original client request. The mechanism ensuring this functionality is implemented as  so-called hook rules:

http://technet.microsoft.com/en-us/library/dd348817(v=ws.10).aspx

Filter hooks help to direct traffic in a Network Load Balancing (NLB) cluster by filtering network packets. If the filter hooks are not properly configured, the NLB cluster will continue to converge and operate normally, however, the server application that is running with NLB will not be able to properly register the hooks.

The essential logic of the hook rules is the following:

At each packet, NLB calls out to the registered drivers (in this case fweng) whether they want to modify how the hash is created.

For example, when a client sends a SYN packet, NLB “asks” TMG’s fweng driver how it should calculate the hash. TMG will tell (depending on its hook rules) to use for example the client source IP for hashing (which is the default behavior). The calculated hash instructs NLB for example that the first node should handle the traffic and pass the SYN to the backend server.

When the server responds to the internal NLB of the TMG array, NLB calls out again to ask TMG how the hash is supposed to be calculated.

Based on the same hook rule set and seeing the packet direction, TMG  tells NLB to hash based on the destination IP, which is again the client IP, so the packet will be handled by the same node as the original packet.

If the hook rule was not present , TMG would tell to use the default behavior (use the source IP), which would result in  calculating the hash based on the  source (server) IP, possibly yielding that a different node is supposed to handle the traffic, which is not what we want.

If  you have a TMG array with several nodes and NLB is enabled, then TMG service creates hook rules at start.

These rules can be checked by executing netsh tmg show nlb from an elevated command prompt, which yields similar output as can be seen below.

Notice the rules have a source and destination range, and a direction based on which TMG can decide what to tell NLB when its called: whether to hash on source (forward) or destination IP (reverse).

clip_image001

A potential problem occurs if hook rules are missing. In this post, we are going to explore a potential cause for missing hook rules.

The below is from a sample test lab which we built based on a particular issue we got reported by a customer:

clip_image002

In  the example above we can see only rules which were created and hash based on source (forward direction) for outgoing scenario. 

You however do not see any reverse rules, indicating that some rules may be missing .

I took those rules from my TMG Array with Internal 10.0.0.0/24, DMZ 192.168.0.0/24 and External 172.20.1.0/24 networks.

Let's imagine a scenario where we have created a publishing rule for a server from DMZ with a listener on External network and you have configured the rule to be half NAT (request appears from client).

Because there is no specific rule for the range external network -> DMZ, DMZ -> external, in both directions we use the default behavior to hash based on the source IP.

As described above, because the hook rule is missing, this may or may not work depending on client IP/published server twin. If the NLB hash algorithm gives the same NLB node ID for both the client and the server IP , it will work. Otherwise, client and server packets will be serviced by different hosts, and the published server responses will be dropped with   the  error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED.

The reason of the issue is lack of some NLB hook rules.

These rules are created at the startup based on network rules. In a real world scenario, when we may have a lot of subnets, it's quite easy to miss a network rule between two networks.

In this case, this is exactly what happened –  there was no network relationship defined between External and DMZ, hence the appropriate rule was never created

Once we add the network rule, the hook rules will be created. I created the rule from External to DMZ network with Route relationship. In the output below you can see how hook rules changed.

clip_image003

Now we have appropriate rules for processing requests from External to DMZ network back and forth, ensuring that we hash using the same IP in both directions. Hence, we should not get error 0xc0040017 FWX_E_TCP_NOT_SYN_PACKEP_DROPPED any more.

If you see the above error, make sure to check whether the appropriate hook rules are present – one of the root causes for missing hook rules can be the missing network relationship definition.

Author:

Vasily Kobylin, Senior Support Engineer, Microsoft EMEA Forefront Edge

Reviewer:

Balint Toth, Senior Support Escalation Engineer, Microsoft EMEA Forefront Edge

Franck Heilmann, Senior Escalation Engineer, Microsoft EMEA Forefront Edge

Categories: NLB, TMG Tags:

MS14-053 – Important: Vulnerability in .NET Framework Could Allow Denial of Service (2990931) – Version: 1.1

Severity Rating: Important
Revision Note: V1.1 (September 17, 2014): V1.1 (September 17, 2014): Bulletin revised to clarify language in the Executive Summary, Mitigating Factors, and Vulnerability FAQ sections that describes the attack vector for CVE-2014-4072. This is an informational change only. Customers who have already successfully installed the update do not have to take any action.
Summary: This security update resolves one privately reported vulnerability in Microsoft .NET Framework. The vulnerability could allow denial of service if an attacker sends a small number of specially crafted requests to an affected .NET-enabled website. By default, ASP.NET is not installed when Microsoft .NET Framework is installed on any supported edition of Microsoft Windows. To be affected by the vulnerability, customers must manually install and enable ASP.NET by registering it with IIS.

Categories: Uncategorized Tags:

What to do if your antivirus subscription has expired

September 16th, 2014 No comments

Phil asks:

I’m new to Windows 8.1. Now that my free security software has expired, how do I go about making Windows Defender my choice security method?

Windows Defender is included with Windows 8 and Windows 8.1 and helps protect your PC against malware (malicious software). Many new computers come with free subscriptions to antivirus software and other security programs from companies other than Microsoft. If the subscription runs out and you don’t want to pay for it, you need to:

  1. Fully uninstall the non-Microsoft security software that came with your computer.
  2. Make sure Windows Defender is turned on.

To uninstall the security software that came with your computer, check the software’s Help file.

Make sure Windows Defender is turned on in Windows 8

  1. Swipe in from the right edge of the screen and tap Search (or if you’re using a mouse, point to the upper-right corner of the screen, move the mouse pointer down, and then click Search).
  2. In the Search box, type Windows Defender.
  3. Tap or click the Windows Defender icon.
  4. Go to Settings, and make sure that Turn on real-time protection (recommended) is selected.
  5. Tap or click Save Changes.

What to do if your antivirus subscription has expired

September 16th, 2014 No comments

Phil asks:

I’m new to Windows 8.1. Now that my free security software has expired, how do I go about making Windows Defender my choice security method?

Windows Defender is included with Windows 8 and Windows 8.1 and helps protect your PC against malware (malicious software). Many new computers come with free subscriptions to antivirus software and other security programs from companies other than Microsoft. If the subscription runs out and you don’t want to pay for it, you need to:

  1. Fully uninstall the non-Microsoft security software that came with your computer.
  2. Make sure Windows Defender is turned on.

To uninstall the security software that came with your computer, check the software’s Help file.

Make sure Windows Defender is turned on in Windows 8

  1. Swipe in from the right edge of the screen and tap Search (or if you’re using a mouse, point to the upper-right corner of the screen, move the mouse pointer down, and then click Search).
  2. In the Search box, type Windows Defender.
  3. Tap or click the Windows Defender icon.
  4. Go to Settings, and make sure that Turn on real-time protection (recommended) is selected.
  5. Tap or click Save Changes.

What to do if your antivirus subscription has expired

September 16th, 2014 No comments

Phil asks:

I’m new to Windows 8.1. Now that my free security software has expired, how do I go about making Windows Defender my choice security method?

Windows Defender is included with Windows 8 and Windows 8.1 and helps protect your PC against malware (malicious software). Many new computers come with free subscriptions to antivirus software and other security programs from companies other than Microsoft. If the subscription runs out and you don’t want to pay for it, you need to:

  1. Fully uninstall the non-Microsoft security software that came with your computer.
  2. Make sure Windows Defender is turned on.

To uninstall the security software that came with your computer, check the software’s Help file.

Make sure Windows Defender is turned on in Windows 8

  1. Swipe in from the right edge of the screen and tap Search (or if you’re using a mouse, point to the upper-right corner of the screen, move the mouse pointer down, and then click Search).
  2. In the Search box, type Windows Defender.
  3. Tap or click the Windows Defender icon.
  4. Go to Settings, and make sure that Turn on real-time protection (recommended) is selected.
  5. Tap or click Save Changes.

MS14-046 – Important: Vulnerability in .NET Framework Could Allow Security Feature Bypass (2984625) – Version: 1.1

Severity Rating: Important
Revision Note: V1.1 (September 16, 2014): Bulletin revised to announce a detection change in the 2966827 update for Microsoft .NET Framework 3.0 Service Pack 2 on Windows 8 and Windows Server 2012. This is a detection change only. There were no changes to the update files. Customers who have already successfully updated their systems do not need to take any action.
Summary: This security update resolves a privately reported vulnerability in Microsoft .NET Framework. The vulnerability could allow security feature bypass if a user visits a specially crafted website. In a web-browsing attack scenario, an attacker who successfully exploited this vulnerability could bypass the Address Space Layout Randomization (ASLR) security feature, which helps protect users from a broad class of vulnerabilities. The security feature bypass by itself does not allow arbitrary code execution. However, an attacker could use this ASLR bypass vulnerability in conjunction with another vulnerability, such as a remote code execution vulnerability, that could take advantage of the ASLR bypass to run arbitrary code.

Categories: Uncategorized Tags:

MS14-055 – Important: Vulnerabilities in Microsoft Lync Server Could Allow Denial of Service (2990928) – Version: 2.0

Severity Rating: Important
Revision Note: V2.0 (September 15, 2014): Bulletin revised to remove Download Center links for Microsoft security update 2982385 for Microsoft Lync Server 2010. See the Update FAQ for details.
Summary: This security update resolves three privately reported vulnerabilities in Microsoft Lync Server. The most severe of these vulnerabilities could allow information disclosure if user clicks on a specially crafted URL. In all cases, however, an attacker would have to convince users to click on the specially crafted URL, typically by getting them to click the URL in an email message or in an Instant Messenger request.

Categories: Uncategorized Tags: