Archive

Archive for December, 2012

Fix it for Security Advisory 2794220 now available

December 31st, 2012 No comments

We have updated Security Advisory 2749920 to include the Fix it we discussed in Saturday’s blog post.  This easy, one-click Fix it is available to everyone and prevents the vulnerability from being used for code execution without affecting your ability to browse the Web. Additionally, applying the Fix it does not require a reboot. While we have still observed only a few attempts to exploit this issue, we encourage all customers to apply this Fix it to help protect their systems.

We continue to work on a security update to address this issue and we’re closely monitoring the threat landscape. If the situation changes, we will post updates here on the MSRC blog and on Twitter at @MSFTSecResponse.

Thank you,

Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

TMG sources outgoing packets with Secondary IP addresses

December 31st, 2012 No comments

 

Hello Everyone! We’ve seen a few cases lately dealing with TMG servers sourcing outgoing packets with secondary IP addresses that have been added to the NICs. This could cause issues in communications between nodes or possibly other issues. One such example that I have seen come across is where a customer had a TMG server being utilized as an internal firewall behind a 3rd party Edge firewall. Clients were utilizing the TMG server as their proxy server. When the http requests left the external interface of the TMG server the packets were sourced with a secondary IP address of the External NIC on the TMG instead of the primary address of that NIC. When the Edge firewall received the packets it dropped them because its rules were configured to only allow packets out when sourced with the primary IP address of the TMG’s external interface. This of course broke internet connectivity for all internal clients.

 

The question at hand is… “Why is the TMG server sourcing packets with a secondary address instead of the primary address of the NIC?”

The answer to that question deals with the differentiation between the Network Stack in Server 2008 and above and Server 2003 and below. Server 2003XP and below were based off the Weak Host Model. Basically, in a Weak Host Model the primary address of the adapter with a route that most closely matches the target IP address is used as the Source IP Address.

 

In server 2008Vista and above we re-architected the Network stack. It is based on the Strong Host Model. In the Strong Host Model the concept of a Primary IP Address doesn’t exist. To determine the IP address that is utilized it looks at the routing table to decide the proper NIC to utilize, then uses the process defined in RFC 3484 to choose the source IP for outbound packets. Here is a basic breakdown of how the windows implementation of RFC 3484 chooses an IP address:

 

Windows Source IP V4 address selection:

– Rule 1 Prefer same address (applies)

– Rule 2 Prefer appropriate scope (applies)

– Rule 3 Avoid deprecated addresses (applies)

– Rule 4 – Prefer home addresses – does not apply to IP v4

– Rule 5 Prefer outgoing Interfaces (applies)

– Rule 6 Prefer matching label – does not apply to IP v4

– Rule 7 Prefer public addresses – does not apply to IP v4

– Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)

"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB."

*This says that the IP with the most high order bits that match the destination of the next hop will be used.

Note: Rule 8 – Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address.

 

For example, use the following addresses as an example of choosing the longest matching prefix:

TMG Servers External IP Addresses:

192.168.1.14/24
&
192.168.1.68/24

Default Gateway:

192.168.1.127

 

Convert these addresses into binary:

192.168.1.14   = 11000000 10101000 00000001 00001110
192.168.1.68   = 11000000 10101000 00000001 01000100
192.168.1.127 = 11000000 10101000 00000001 01111111

 

The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. This would cause the server to utilize what was originally defined as the “secondary” as the Source IP address of outgoing packets.

 

*For more information on RFC 3484 please refer to the following link: http://www.ietf.org/rfc/rfc3484.txt . Please note that IPv6 is referenced in RFC. Windows utilize the same process for IPv4 sourcing.

You can also review the following TechNet article for supported document details on the above information:

The functionality for source IP address selection in Windows Server 2008 and in Windows Vista differs from the corresponding functionality in earlier versions of Windows
http://support.microsoft.com/kb/969029

 

 

So now we know why your TMG server may be sourcing your packets with what you call your “Secondary IP Address”. It isn’t TMG at all. It is the default behavior of the server itself. Your server version is Server 2008 or above. The question is…

 

“Can I configure my Server 2008 or above in a way that it will only utilize the first IP address as a Source address?”

The answer to that is YES! There is actually a Netsh command that can be utilized to add IP addresses.  In that command you use the “SkipAsSource” flag and it will no longer use the IP address you are adding as a Source IP Address. This means that you will have to temporarily remove the IP Address you are having the issues with then re-add them utilizing the Netsh command (This means you will have to have a maintenance window!). Here are examples of the command lines you will use:

 

Server 2008:
Netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true

Server 2008 R2:

Netsh int ipv4 add address <Interface Name> <ip address> skipassource=true

 

* For details and prerequisites to utilize these commands please refer to the following articles:

 

All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;975808

 

IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184

 

 

Keep in mind that I gave only one specific example where this may be causing an issue.  There may be other problems you run into where the Netsh entry I listed may help you out.  No telling… it may not even be on your TMG servers.  Maybe you see the issue on your UAG servers, or any other server for that fact. 

 

I hope the information provided helps out!

 

Author

Brett Crane – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Reviewer

Richard Barker – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Categories: Uncategorized Tags:

TMG sources outgoing packets with Secondary IP addresses

December 31st, 2012 No comments

 

Hello Everyone! We’ve seen a few cases lately dealing with TMG servers sourcing outgoing packets with secondary IP addresses that have been added to the NICs. This could cause issues in communications between nodes or possibly other issues. One such example that I have seen come across is where a customer had a TMG server being utilized as an internal firewall behind a 3rd party Edge firewall. Clients were utilizing the TMG server as their proxy server. When the http requests left the external interface of the TMG server the packets were sourced with a secondary IP address of the External NIC on the TMG instead of the primary address of that NIC. When the Edge firewall received the packets it dropped them because its rules were configured to only allow packets out when sourced with the primary IP address of the TMG’s external interface. This of course broke internet connectivity for all internal clients.

 

The question at hand is… “Why is the TMG server sourcing packets with a secondary address instead of the primary address of the NIC?”

The answer to that question deals with the differentiation between the Network Stack in Server 2008 and above and Server 2003 and below. Server 2003\XP and below were based off the Weak Host Model. Basically, in a Weak Host Model the primary address of the adapter with a route that most closely matches the target IP address is used as the Source IP Address.

 

In server 2008\Vista and above we re-architected the Network stack. It is based on the Strong Host Model. In the Strong Host Model the concept of a Primary IP Address doesn’t exist. To determine the IP address that is utilized it looks at the routing table to decide the proper NIC to utilize, then uses the process defined in RFC 3484 to choose the source IP for outbound packets. Here is a basic breakdown of how the windows implementation of RFC 3484 chooses an IP address:

 

Windows Source IP V4 address selection:

– Rule 1 Prefer same address (applies)

– Rule 2 Prefer appropriate scope (applies)

– Rule 3 Avoid deprecated addresses (applies)

– Rule 4 – Prefer home addresses – does not apply to IP v4

– Rule 5 Prefer outgoing Interfaces (applies)

– Rule 6 Prefer matching label – does not apply to IP v4

– Rule 7 Prefer public addresses – does not apply to IP v4

– Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)

"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB."

*This says that the IP with the most high order bits that match the destination of the next hop will be used.

Note: Rule 8 – Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address.

 

For example, use the following addresses as an example of choosing the longest matching prefix:

TMG Servers External IP Addresses:

192.168.1.14/24
&
192.168.1.68/24

Default Gateway:

192.168.1.127

 

Convert these addresses into binary:

192.168.1.14   = 11000000 10101000 00000001 00001110
192.168.1.68   = 11000000 10101000 00000001 01000100
192.168.1.127 = 11000000 10101000 00000001 01111111

 

The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. This would cause the server to utilize what was originally defined as the “secondary” as the Source IP address of outgoing packets.

 

*For more information on RFC 3484 please refer to the following link: http://www.ietf.org/rfc/rfc3484.txt . Please note that IPv6 is referenced in RFC. Windows utilize the same process for IPv4 sourcing.

You can also review the following TechNet article for supported document details on the above information:

The functionality for source IP address selection in Windows Server 2008 and in Windows Vista differs from the corresponding functionality in earlier versions of Windows
http://support.microsoft.com/kb/969029

 

 

So now we know why your TMG server may be sourcing your packets with what you call your “Secondary IP Address”. It isn’t TMG at all. It is the default behavior of the server itself. Your server version is Server 2008 or above. The question is…

 

“Can I configure my Server 2008 or above in a way that it will only utilize the first IP address as a Source address?”

The answer to that is YES! There is actually a Netsh command that can be utilized to add IP addresses.  In that command you use the “SkipAsSource” flag and it will no longer use the IP address you are adding as a Source IP Address. This means that you will have to temporarily remove the IP Address you are having the issues with then re-add them utilizing the Netsh command (This means you will have to have a maintenance window!). Here are examples of the command lines you will use:

 

Server 2008:
Netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true

Server 2008 R2:

Netsh int ipv4 add address <Interface Name> <ip address> skipassource=true

 

* For details and prerequisites to utilize these commands please refer to the following articles:

 

All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;975808

 

IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184

 

 

Keep in mind that I gave only one specific example where this may be causing an issue.  There may be other problems you run into where the Netsh entry I listed may help you out.  No telling… it may not even be on your TMG servers.  Maybe you see the issue on your UAG servers, or any other server for that fact. 

 

I hope the information provided helps out!

 

Author

Brett Crane – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Reviewer

Richard Barker – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Categories: Uncategorized Tags:

TMG sources outgoing packets with Secondary IP addresses

December 31st, 2012 No comments

 

Hello Everyone! We’ve seen a few cases lately dealing with TMG servers sourcing outgoing packets with secondary IP addresses that have been added to the NICs. This could cause issues in communications between nodes or possibly other issues. One such example that I have seen come across is where a customer had a TMG server being utilized as an internal firewall behind a 3rd party Edge firewall. Clients were utilizing the TMG server as their proxy server. When the http requests left the external interface of the TMG server the packets were sourced with a secondary IP address of the External NIC on the TMG instead of the primary address of that NIC. When the Edge firewall received the packets it dropped them because its rules were configured to only allow packets out when sourced with the primary IP address of the TMG’s external interface. This of course broke internet connectivity for all internal clients.

 

The question at hand is… “Why is the TMG server sourcing packets with a secondary address instead of the primary address of the NIC?”

The answer to that question deals with the differentiation between the Network Stack in Server 2008 and above and Server 2003 and below. Server 2003\XP and below were based off the Weak Host Model. Basically, in a Weak Host Model the primary address of the adapter with a route that most closely matches the target IP address is used as the Source IP Address.

 

In server 2008\Vista and above we re-architected the Network stack. It is based on the Strong Host Model. In the Strong Host Model the concept of a Primary IP Address doesn’t exist. To determine the IP address that is utilized it looks at the routing table to decide the proper NIC to utilize, then uses the process defined in RFC 3484 to choose the source IP for outbound packets. Here is a basic breakdown of how the windows implementation of RFC 3484 chooses an IP address:

 

Windows Source IP V4 address selection:

– Rule 1 Prefer same address (applies)

– Rule 2 Prefer appropriate scope (applies)

– Rule 3 Avoid deprecated addresses (applies)

– Rule 4 – Prefer home addresses – does not apply to IP v4

– Rule 5 Prefer outgoing Interfaces (applies)

– Rule 6 Prefer matching label – does not apply to IP v4

– Rule 7 Prefer public addresses – does not apply to IP v4

– Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)

"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB."

*This says that the IP with the most high order bits that match the destination of the next hop will be used.

Note: Rule 8 – Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address.

 

For example, use the following addresses as an example of choosing the longest matching prefix:

TMG Servers External IP Addresses:

192.168.1.14/24
&
192.168.1.68/24

Default Gateway:

192.168.1.127

 

Convert these addresses into binary:

192.168.1.14   = 11000000 10101000 00000001 00001110
192.168.1.68   = 11000000 10101000 00000001 01000100
192.168.1.127 = 11000000 10101000 00000001 01111111

 

The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. This would cause the server to utilize what was originally defined as the “secondary” as the Source IP address of outgoing packets.

 

*For more information on RFC 3484 please refer to the following link: http://www.ietf.org/rfc/rfc3484.txt . Please note that IPv6 is referenced in RFC. Windows utilize the same process for IPv4 sourcing.

You can also review the following TechNet article for supported document details on the above information:

The functionality for source IP address selection in Windows Server 2008 and in Windows Vista differs from the corresponding functionality in earlier versions of Windows
http://support.microsoft.com/kb/969029

 

 

So now we know why your TMG server may be sourcing your packets with what you call your “Secondary IP Address”. It isn’t TMG at all. It is the default behavior of the server itself. Your server version is Server 2008 or above. The question is…

 

“Can I configure my Server 2008 or above in a way that it will only utilize the first IP address as a Source address?”

The answer to that is YES! There is actually a Netsh command that can be utilized to add IP addresses.  In that command you use the “SkipAsSource” flag and it will no longer use the IP address you are adding as a Source IP Address. This means that you will have to temporarily remove the IP Address you are having the issues with then re-add them utilizing the Netsh command (This means you will have to have a maintenance window!). Here are examples of the command lines you will use:

 

Server 2008:
Netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true

Server 2008 R2:

Netsh int ipv4 add address <Interface Name> <ip address> skipassource=true

 

* For details and prerequisites to utilize these commands please refer to the following articles:

 

All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;975808

 

IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184

 

 

Keep in mind that I gave only one specific example where this may be causing an issue.  There may be other problems you run into where the Netsh entry I listed may help you out.  No telling… it may not even be on your TMG servers.  Maybe you see the issue on your UAG servers, or any other server for that fact. 

 

I hope the information provided helps out!

 

Author

Brett Crane – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Reviewer

Richard Barker – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Categories: Uncategorized Tags:

TMG sources outgoing packets with Secondary IP addresses

December 31st, 2012 No comments

 

Hello Everyone! We’ve seen a few cases lately dealing with TMG servers sourcing outgoing packets with secondary IP addresses that have been added to the NICs. This could cause issues in communications between nodes or possibly other issues. One such example that I have seen come across is where a customer had a TMG server being utilized as an internal firewall behind a 3rd party Edge firewall. Clients were utilizing the TMG server as their proxy server. When the http requests left the external interface of the TMG server the packets were sourced with a secondary IP address of the External NIC on the TMG instead of the primary address of that NIC. When the Edge firewall received the packets it dropped them because its rules were configured to only allow packets out when sourced with the primary IP address of the TMG’s external interface. This of course broke internet connectivity for all internal clients.

 

The question at hand is… “Why is the TMG server sourcing packets with a secondary address instead of the primary address of the NIC?”

The answer to that question deals with the differentiation between the Network Stack in Server 2008 and above and Server 2003 and below. Server 2003\XP and below were based off the Weak Host Model. Basically, in a Weak Host Model the primary address of the adapter with a route that most closely matches the target IP address is used as the Source IP Address.

 

In server 2008\Vista and above we re-architected the Network stack. It is based on the Strong Host Model. In the Strong Host Model the concept of a Primary IP Address doesn’t exist. To determine the IP address that is utilized it looks at the routing table to decide the proper NIC to utilize, then uses the process defined in RFC 3484 to choose the source IP for outbound packets. Here is a basic breakdown of how the windows implementation of RFC 3484 chooses an IP address:

 

Windows Source IP V4 address selection:

– Rule 1 Prefer same address (applies)

– Rule 2 Prefer appropriate scope (applies)

– Rule 3 Avoid deprecated addresses (applies)

– Rule 4 – Prefer home addresses – does not apply to IP v4

– Rule 5 Prefer outgoing Interfaces (applies)

– Rule 6 Prefer matching label – does not apply to IP v4

– Rule 7 Prefer public addresses – does not apply to IP v4

– Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)

"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB."

*This says that the IP with the most high order bits that match the destination of the next hop will be used.

Note: Rule 8 – Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address.

 

For example, use the following addresses as an example of choosing the longest matching prefix:

TMG Servers External IP Addresses:

192.168.1.14/24
&
192.168.1.68/24

Default Gateway:

192.168.1.127

 

Convert these addresses into binary:

192.168.1.14   = 11000000 10101000 00000001 00001110
192.168.1.68   = 11000000 10101000 00000001 01000100
192.168.1.127 = 11000000 10101000 00000001 01111111

 

The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. This would cause the server to utilize what was originally defined as the “secondary” as the Source IP address of outgoing packets.

 

*For more information on RFC 3484 please refer to the following link: http://www.ietf.org/rfc/rfc3484.txt . Please note that IPv6 is referenced in RFC. Windows utilize the same process for IPv4 sourcing.

You can also review the following TechNet article for supported document details on the above information:

The functionality for source IP address selection in Windows Server 2008 and in Windows Vista differs from the corresponding functionality in earlier versions of Windows
http://support.microsoft.com/kb/969029

 

 

So now we know why your TMG server may be sourcing your packets with what you call your “Secondary IP Address”. It isn’t TMG at all. It is the default behavior of the server itself. Your server version is Server 2008 or above. The question is…

 

“Can I configure my Server 2008 or above in a way that it will only utilize the first IP address as a Source address?”

The answer to that is YES! There is actually a Netsh command that can be utilized to add IP addresses.  In that command you use the “SkipAsSource” flag and it will no longer use the IP address you are adding as a Source IP Address. This means that you will have to temporarily remove the IP Address you are having the issues with then re-add them utilizing the Netsh command (This means you will have to have a maintenance window!). Here are examples of the command lines you will use:

 

Server 2008:
Netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true

Server 2008 R2:

Netsh int ipv4 add address <Interface Name> <ip address> skipassource=true

 

* For details and prerequisites to utilize these commands please refer to the following articles:

 

All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;975808

 

IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184

 

 

Keep in mind that I gave only one specific example where this may be causing an issue.  There may be other problems you run into where the Netsh entry I listed may help you out.  No telling… it may not even be on your TMG servers.  Maybe you see the issue on your UAG servers, or any other server for that fact. 

 

I hope the information provided helps out!

 

Author

Brett Crane – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Reviewer

Richard Barker – Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team

Categories: Uncategorized Tags:

Fake apps: Behind the effective social strategy of fraudulent paid-archives

December 31st, 2012 No comments

In my previous blog “Fake apps and the lure of alternative sources,” I discussed a fraudulent scheme that takes advantage of known, legitimate and free applications. Unlike rogues and ransomware which use threats and force to influence their victims, the social engineering techniques employed by a fake installer are less aggressive yet, interestingly, more deceptive.

This technique is widely used in the Win32/Pameseg family – our detection for a family of “paid archives” that present as fake installers. These “installers” persuade their victims into sending premium SMS messages to successfully complete an installation.

Trojan:Win32/Pameseg.A and TrojanDownloader:MSIL/Pameseg.A are detections for recent variants that have been found taking advantage of the new release of Windows 8, while Trojan:MacOS_X/Pameseg.A has been found targeting Mac OS X users.

If we take a closer look at the fraudulent scheme used, the social strategy starts with the user committing to pursue an attractive proposition. This may include wanting to find an installer for pirated software, key or serial number generators, or simply the installer of a legitimate application. In order to achieve this goal, the user will need to search for information. If the user is unsure or does not even know where the legitimate and clean distribution is, then it is likely they will spend time searching and trying from one or more unknown distribution channels; a problem that brings opportunity to the operators and affiliates of fraudulent paid archives.

Multi-armed bandits, courtesy of Microsoft Research - Silicon Valley (MSR-SVC)

Figure 1: Illustration courtesy of the Multi-armed bandits project at Microsoft Research – Silicon Valley (MSR-SVC)

 

Why is this a problem? Because the user searching from an unknown distribution platform is playing a game of chances – think of it as a probability of finding a match from a random search result. This user’s scenario can be described as the multi-armed bandits (MAB) problem, in which a player faces several slot machines that look identical but produce different winnings. The only way the player can learn and maximize the distribution of the reward from any of the slot machines is by playing all of the machines. The player can’t know which machine will provide the reward until they’ve tried the machine.

In this case, the perpetrators of fraudulent paid archives simply play their chances by offering the distribution. The intent here is that a user may search for a particular piece of software and end up choosing to download malware – thinking they have selected a legitimate copy of the software.

Upon installation of the software, a deceptive scheme is used, which we can relate to as the “low-ball” technique. Using this technique, the user is led to believe they are making a free choice; however, the choice ultimately leads the user to a targeted behavior of downloading and executing the installer. When the installation is almost complete, as seen in the Win32/Pameseg family, the deceptive scheme appears by requesting a cost – a cost that was not previously made clear to the user. This hidden cost is revealed through a second request, for example asking the user to send premium SMS message to get an activation code to continue the installation.

Trojan:MacOS_X/Pameseg.A installer

Figure 2: Fake installer for Trojan:MacOS_X/Pameseg.A

 

The effectiveness of the low-ball technique is due to the fact that the user has already spent time searching for information, explored a distribution, and committed to an idea. This leads the user to perform the voluntary actions of manually downloading the file, storing it locally and initiating the installation process. This is a series of voluntary actions that the user may have not agreed to had they known of the increasing expectation or cost associated with the second request (for money). However, because the low-ball technique is a persuasion method based on a sequential request, the user may act and agree on the second request to comply with the existing “agreement”.
For example, the Pameseg family asks the user to comply with the installation by providing an activation code that is only available after sending a premium SMS message. The perpetrators are relying on the user thinking “I’ve spent this much time and effort on finding and downloading this, I may as well just pay and get it fully unlocked.”

This monetization model of paid-archives is an intentional deceit, a deception deliberately targeting innocent online users in order to secure an unfair or unlawful financial gain. Because it is an easy money-making scheme, this monetization model attracts distributions and affiliates in which these perpetrators continue to drive the proliferation of this scheme (see the paper “Less aggressive, more effective: Social engineering with paid archives,” published in the Virus Bulletin Conference 2012 proceedings).

We advise users to consider the following measures as an important precaution against these schemes:

  • When searching for a source to download from, make sure to carefully check the source. Ensure you download the installer or application from legitimate and trusted sources.
  • Be aware of any online transaction you make. Ensure you understand the terms of the software download, especially when it involves installation of “free” applications and, most importantly, those that require you to perform financial transactions.
  • If you’re unsure, find someone you know who can provide helpful advice.

Be safe online and enjoy the festive season!

 

Methusela Cebrian Ferrer
MMPC Melbourne

Categories: Uncategorized Tags:

Microsoft Releases Security Advisory 2794220

December 29th, 2012 No comments

Today, we released Security Advisory 2794220 regarding an issue that impacts Internet Explorer 6, 7, and 8. We are only aware of a very small number of targeted attacks at this time. This issue allows remote code execution if users browse to a malicious website with an affected browser. This would typically occur by an attacker convincing someone to click a link in an email or instant message.

Internet Explorer 9 and 10 are not affected by this issue, so upgrading to these versions will help protect you from this issue.

While we are actively working to develop a security update to address this issue, we encourage customers using affected versions of Internet Explorer to deploy the following workarounds and mitigations included in the advisory to help protect themselves: 

  • 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.
  • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
    This will help prevent exploitation by providing mitigations to protect against this issue and should not affect usability of websites. An easy guide for EMET installation and configuration is available in
    KB2458544.

Over on the SRD blog, MSRC’s own Jonathan Ness and Cristian Craioveanu go over some of the issue details. We are also actively working to package an easy, one-click Fix it solution that will help protect your computer. In their blog, Jonathan and Cristian describe the shim that will be included in the Fix it, and how it will be able to be used to help prevent the exploit from succeeding. We expect the Fix it will be available in the next few days and will update this blog when it is ready.

As always, we encourage people 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 folks 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 if the situation changes, we will post updates here on the MSRC blog and on Twitter at @MSFTSecResponse.

Thank you,

Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

Update signature definitions to resolve performance issues in definitions starting with 1.141.2400.0

December 28th, 2012 No comments

Some users of Microsoft antimalware products have reported a performance issue with signature definition versions starting with 1.141.2400.0 (12/21/2012 1920 UTC).

The current definition files, since 1.141.2639.0 (12/27/2012 0625 UTC), resolve this issue. If you have a signature set in the affected range, please update to the current definition files.

Shannon Sabens
MMPC

Categories: Uncategorized Tags:

Query for Advanced CA Configuration Options

December 27th, 2012 No comments

It is very common to check the configuration of any certification authority using certutil –getreg command. The command will allow a CA administrator to view the configured settings at a glance.

 

 

 But what if you need to configure advanced settings on your CA? How can you find a setting required for your compliance audit?

 

Well, this is simple! You can still use the common certutil –getreg command but now, add the verbose switch (-v). The command’s output will be similar to the screenshot below

As you probably noticed, all supported symbol names are displayed. The ones indented and in parentheses are supported bits that could be set, but currently are not. Any symbol without parentheses is configured on your CA. The symbolic names may be of some help to identify each bit’s purpose. You can perform a quick research on TechNet or MSDN to further understand and deploy each bit.

Amer F. Kamal

Senior Premier Field Engineer

 

Categories: ADCS, Advanced CA Configuration Tags:

Query for Advanced CA Configuration Options

December 27th, 2012 No comments

It is very common to check the configuration of any certification authority using certutil –getreg command. The command will allow a CA administrator to view the configured settings at a glance.

 

 

 But what if you need to configure advanced settings on your CA? How can you find a setting required for your compliance audit?

 

Well, this is simple! You can still use the common certutil –getreg command but now, add the verbose switch (-v). The command’s output will be similar to the screenshot below

As you probably noticed, all supported symbol names are displayed. The ones indented and in parentheses are supported bits that could be set, but currently are not. Any symbol without parentheses is configured on your CA. The symbolic names may be of some help to identify each bit’s purpose. You can perform a quick research on TechNet or MSDN to further understand and deploy each bit.

Amer F. Kamal

Senior Premier Field Engineer

 

Categories: ADCS, Advanced CA Configuration Tags:

Query for Advanced CA Configuration Options

December 27th, 2012 No comments

It is very common to check the configuration of any certification authority using certutil –getreg command. The command will allow a CA administrator to view the configured settings at a glance.

 

 

 But what if you need to configure advanced settings on your CA? How can you find a setting required for your compliance audit?

 

Well, this is simple! You can still use the common certutil –getreg command but now, add the verbose switch (-v). The command’s output will be similar to the screenshot below

As you probably noticed, all supported symbol names are displayed. The ones indented and in parentheses are supported bits that could be set, but currently are not. Any symbol without parentheses is configured on your CA. The symbolic names may be of some help to identify each bit’s purpose. You can perform a quick research on TechNet or MSDN to further understand and deploy each bit.

Amer F. Kamal

Senior Premier Field Engineer

 

Categories: ADCS, Advanced CA Configuration Tags:

Top 10 security stories of 2012

December 27th, 2012 No comments

From the latest scams and fraud to how, when, and why to update your computer, here are the stories that you viewed and clicked on the most this year.

Download security update for Internet Explorer. In September, Microsoft released a security update for Internet Explorer. To help protect your computer, visit Windows Update to download and install the update and ensure that you have automatic updating turned on.

Update your browserIn February, if you had automatic updating turned on, Windows Update automatically upgraded you to Internet Explorer 9.  Now you can get Internet Explorer 10.

Is my computer up to date? In March, you clicked on this blog entry to learn how to turn on automatic updating and to make sure that your computer had all of the latest updates.

Beware of ransomware. Nearly a year ago, a lot of you stopped by to learn about the resurgence of this scam. It launches a pop-up window warning that illegal material has been found on your computer and then locks you out of your computer unless you pay a fee. It’s still around, and we recently offered new guidance to help you deal with it.

Protect yourself from online tracking. Earlier this year we reported on Tracking Protection, which was a new feature in Internet Explorer 9. Read more about how user privacy protection has evolved and why it is turned on by default in Internet Explorer 10.

Here are five more stories that were popular with you this year:

For more information on the top online safety stories of this year, visit the Trustworthy Computing blog.
 
 

Top 10 security stories of 2012

December 27th, 2012 No comments

From the latest scams and fraud to how, when, and why to update your computer, here are the stories that you viewed and clicked on the most this year.

Download security update for Internet Explorer. In September, Microsoft released a security update for Internet Explorer. To help protect your computer, visit Windows Update to download and install the update and ensure that you have automatic updating turned on.

Update your browserIn February, if you had automatic updating turned on, Windows Update automatically upgraded you to Internet Explorer 9.  Now you can get Internet Explorer 10.

Is my computer up to date? In March, you clicked on this blog entry to learn how to turn on automatic updating and to make sure that your computer had all of the latest updates.

Beware of ransomware. Nearly a year ago, a lot of you stopped by to learn about the resurgence of this scam. It launches a pop-up window warning that illegal material has been found on your computer and then locks you out of your computer unless you pay a fee. It’s still around, and we recently offered new guidance to help you deal with it.

Protect yourself from online tracking. Earlier this year we reported on Tracking Protection, which was a new feature in Internet Explorer 9. Read more about how user privacy protection has evolved and why it is turned on by default in Internet Explorer 10.

Here are five more stories that were popular with you this year:

For more information on the top online safety stories of this year, visit the Trustworthy Computing blog.
 
 

Virus protection: Real or Rogue?

December 25th, 2012 No comments

The newly launched Real vs. Rogue Facebook app from Microsoft features an interactive quiz to help you tell if a security warning is from your real antivirus software or from rogue security software.

There has been an increase in rogue security software over the last few years. It often piggybacks on new software releases and displays fake warnings with the intent to confuse unfamiliar users. This Real vs. Rogue Facebook app can help all of us think twice before we click anywhere near a security warning.

Take the Real vs. Rogue quiz to test your knowledge

 

 

Categories: Uncategorized Tags:

Virus protection: Real or Rogue?

December 25th, 2012 No comments

The newly launched Real vs. Rogue Facebook app from Microsoft features an interactive quiz to help you tell if a security warning is from your real antivirus software or from rogue security software.

There has been an increase in rogue security software over the last few years. It often piggybacks on new software releases and displays fake warnings with the intent to confuse unfamiliar users. This Real vs. Rogue Facebook app can help all of us think twice before we click anywhere near a security warning.

Take the Real vs. Rogue quiz to test your knowledge

 

 

Categories: Uncategorized Tags:

Korean gaming malware – served 3 ways

December 21st, 2012 No comments

Recently, we’ve seen similar activities being performed by different malware that monitor online Korean applications. Mostly, the applications they monitor are card games, such as those in Figure 1.

Examples of online Korean games that are being monitored. (Source: http://www.hangame.com)
Figure 1: Examples of online Korean games that are being monitored. (Source: http://www.hangame.com)

 

The following applications are monitored if found running on the system:

  • LASPOKER.EXE
  • highlow2.exe
  • baduki.exe
  • duelpoker.exe
  • HOOLA3.exe
  • poker7.exe
  • FRN.exe

The first malware is Trojan:Win32/Urelas.C. Written in Delphi, this malware uses a typical spying technique. It takes screenshots of a user’s gaming activity by looking for the processes listed above at certain positions on the screen; these screenshots could then be used to observe the gaming behavior of the compromised user. It sends copies of the screenshots it captures to a remote server in JPG, TIFF, or BMP picture format and also gathers other information from the compromised system, such as the computer name and user login details. 

The second malware is Trojan:Win32/Gupboot.A. This malware takes things a step further, introducing a bootkit component and reusing code from Urelas to overwrite the MBR (which we detect as Trojan:DOS/Gupboot.A). Part of this malware’s payload is to allow kernel-mode hooking to hide the malware process and its suspicious activities from the user, making the system run in a compromised state.

Like most malware that overwrites the MBR, the main intent is to use the malware’s 16-bit loader to execute the payload. The malware uses its own copy of explorer.exe (dropped as temp1234.dat) written on the physical sector and redirects execution of the system’s original explorer.exe to the malware copy (see Figure 2). This type of behaviour is also discussed in the Bitdefender LABS blog “Plite bootkit spies on gamers”

Portion of Trojan:DOS/Gubpoot.A written on disk with intenet to replace C:Windows\explorer.exe execution
Figure 2: Portion of Trojan:DOS/Gubpoot.A written on disk with intent to replace C:Windows\explorer.exe execution

Also found in the body of the malware code is a zip archive that contains an executable detected as Trojan:Win32/Gupboot.A.

The third and last malware is Backdoor:Win32/Blohi.B. The malware is compiled in VB and usually arrives disguised as a game bundled in an NSIS installer with names such as Plants vs. Zombies, StarCraft and others. Once installed, it pings http://blog.naver.com/PostView.nhn, a very popular Korean search engine, to test for an internet connection. It logs keystrokes, monitors the processes listed above (if they exist) and has predefined backdoor commands that can modify the process list, take screenshots and uninstall the malware. It can also display a fake blue screen (see Figure 3) – possibly to force the user into rebooting their computer so that the Blohi malware can install other malware.

Fake blue screen
Figure 3: Fake blue screen

 

We also observed that these threats are most prevalent in Korea compared to other geographical locations, as seen from the following reports for the month of November 2012.

Table 1: Urelas infection
Table 1: Urelas infection

 

Table 2: Gupboot infection
Table 2: Gupboot infection

 

Table 3: Blohi infection
Table 3: Blohi infection

 

The aim of the malware authors is to gather information, for example:

  • User login details
  • Credit card details – used for purchasing game money and avatar upgrades
  • Korean ID – similar to a social security number, required for registration and verification purposes
  • Screenshots – taken to observe the gaming behavior of the user and possibly to provide an advantage to the authors if they choose to play with the user

MMPC strongly recommends users be cautious with files downloaded from the internet. Always verify that it comes from a reputable source before executing the binary. In the case of Blohi and other malware posing as installers, instead of playing a full version of the game, you might end up getting played by malware authors.

Marianne Mallen
MMPC

Categories: malware research Tags:

3 ways to increase your mobile safety this holiday season

December 20th, 2012 No comments

If your holiday plans include travel, the following tips can help you stay safer online with a mobile device.

  • Make sure your laptop or tablet has up-to-date antivirus and antispyware software installed. Windows 8 includes antivirus protection that’s turned on by default. If your computer isn’t running Windows 8, download Microsoft Security Essentials for free.
  • Choose the most secure Wi-Fi connection. Both Windows 7 and Windows 8 can help you evaluate and minimize network security risks.
  • Avoid entering passwords, credit card numbers, or other financial information on a less secure public network.

Get more tips on using public computers and wireless devices more safely

Categories: Uncategorized Tags:

3 ways to increase your mobile safety this holiday season

December 20th, 2012 No comments

If your holiday plans include travel, the following tips can help you stay safer online with a mobile device.

  • Make sure your laptop or tablet has up-to-date antivirus and antispyware software installed. Windows 8 includes antivirus protection that’s turned on by default. If your computer isn’t running Windows 8, download Microsoft Security Essentials for free.
  • Choose the most secure Wi-Fi connection. Both Windows 7 and Windows 8 can help you evaluate and minimize network security risks.
  • Avoid entering passwords, credit card numbers, or other financial information on a less secure public network.

Get more tips on using public computers and wireless devices more safely

Categories: Uncategorized Tags:

Viewing Expired Certificate Revocation List (CRL)

December 20th, 2012 No comments

Many customers must perform a regulatory audit annually to comply with industry standards and business trends. Recently I was contacted by one of my customers, who was not able to view all of Certificate Revocation Lists (CRLs) issued by their Enterprise Certification Authority. The customer mentioned they were able to view these CRLs on a Windows Server 2003 Certification Authorities but cannot view them on Windows Server 2008 R2 Enterprise Certification Authorities.

 

Windows Server 2008 and Windows Server 2012 Certification Authorities by default delete expired CRLs when a new one is issued. This option can be reversed to preserve expired CRLs, but has to be implemented before your audit. To preserve expired CRLs run the following commands:

certutil –setreg CACRLFlags -CRLF_DELETE_EXPIRED_CRLS

net stop certsvc

net start certsvc

 

Furthermore, you can view CRLs by running this command:

 certutil -view -out “CRLThisPublish,CRLNumber,CRLCount” CRL


The Certification Authority Console by default will not display Certificate Revocation List (CRL)history as noted in the screenshot below.

 

 

You can change this behavior by running certsvc.msc /e from

 Amer F Kamal

Senior Premier Field Engineer

 

 

Categories: Uncategorized Tags:

Viewing Expired Certificate Revocation List (CRL)

December 20th, 2012 No comments

Many customers must perform a regulatory audit annually to comply with industry standards and business trends. Recently I was contacted by one of my customers, who was not able to view all of Certificate Revocation Lists (CRLs) issued by their Enterprise Certification Authority. The customer mentioned they were able to view these CRLs on a Windows Server 2003 Certification Authorities but cannot view them on Windows Server 2008 R2 Enterprise Certification Authorities.

 

Windows Server 2008 and Windows Server 2012 Certification Authorities by default delete expired CRLs when a new one is issued. This option can be reversed to preserve expired CRLs, but has to be implemented before your audit. To preserve expired CRLs run the following commands:

certutil –setreg CA\CRLFlags -CRLF_DELETE_EXPIRED_CRLS

net stop certsvc

net start certsvc

 

Furthermore, you can view CRLs by running this command:

 certutil -view -out “CRLThisPublish,CRLNumber,CRLCount” CRL


The Certification Authority Console by default will not display Certificate Revocation List (CRL)history as noted in the screenshot below.

 

 

You can change this behavior by running certsvc.msc /e from

 Amer F Kamal

Senior Premier Field Engineer

 

 

Categories: Uncategorized Tags: