Archive

Archive for April, 2012

An interesting case of Mac OSX malware

April 30th, 2012 No comments

In June 2009, Microsoft issued security update MS09-027, which fixed a remote code execution vulnerability in the Mac version of Microsoft Office. Despite the availability of the bulletin (and the passage of time), not every machine is up to date yet – which is how nearly three years later, malware has emerged that exploits the issue on machines running Office on Mac OS X. Fortunately, our data indicates that this malware is not widespread, but during our investigation we found a few interesting facts we’d like to share with you.

For our investigation, we used a malware sample (SHA1: 445959611bc2480357057664bb597c803a349386) that is detected as Exploit:MacOS_X/MS09-027.A.

Overall execution flow

Figure 1 – Overall Execution Flow

Firstly, the vulnerability is a stack-based buffer overflow – the attack code could corrupt variables and return addresses located on the stack. As we analyzed the malware, we found that the malware author managed to corrupt a local variable and used that corrupted variable to deploy ‘stage 1’ shellcode to a designated area. This corrupted variable is later used for a target address and is where the stage 1 shellcode is copied. The corrupted return address points to this target address as well.

This target address is important, as, with Snow Leopard, we could confirm that it was used to exploit a specific location on the heap that is writable and also executable. The point is, that with Lion, that specific memory address can’t be written, so the exploit fails.

We can assume that this malware itself is targeting only Snow Leopard or lower versions of Mac OSX. That means the attacker had knowledge about the target environment beforehand. That includes the target operating system, application patch levels, etc.

Stage 1 shellcode

Figure 2 Stage 1 Shellcode

This stage 1 shellcode leads to stage 2 shellcode, which is located in memory. The stage 2 shellcode is actually where the infection of the system occurs. The stage 2 shellcode creates three files:

  • /tmp/launch-hs
  • /tmp/launch-hse
  • /tmp/file.doc

 File creation by stage 2 shellcode

Figure 3 File Creation by Stage 2 Shellcode

As you can see from the above picture, the exploit attack code uses typical Unix style shellcode to run system calls. So far, this is nothing new.

Later in the shellcode, the file “/tmp/launch-hs” is executed by a system call to “execve” to execute commands. The contents of “/tmp/launch-hs” should be a shell script or executable.

Figure 4 Execution of /tmp/launch-hs script file

We looked into the the contents of the “/tmp/launch-hs“, and it appears like following:

Contents of "/tmp/launch-hs" script

Figure 5 /tmp/launch-hs script contents

It is just a tiny shell script that runs “/tmp/launch-hs” and and opens “/tmp/file.doc“. The file “/tmp/launch-hse” should be the main binary that contains all the malicious code. Also “/tmp/file.doc” is a fake document file that will be displayed to the user to deceive the user from seeing any abnormalities or malicious symptoms.

The main payload file is “/tmp/launch-hse” – it is a Mach-O format, or standard executable format, for Mac OSX. This binary a command and control (C&C) agent that communicates with a C&C server (master) to perform unauthorized actions that are similar to other C&C bot clients. The function names give clues that might indicate that this binary is connecting to a C&C server, parses command from it and performs file retrieval or creates process.

Peek into the function names gives you an idea

Figure 6 Peek into the function names gives you an idea.

The main difference about this malware is that it is written for Mac OSX. For example, if you look into a “RunFile” function, which runs a command on the infected machine, you can see that it’s a Mac OSX version of backdoor. Basically it runs a command supplied from the C&C server.

RunFile function

Figure 7 RunFile function

No operating system that exists outside a laboratory is entirely immune to malware. As different operating systems continue to gain in popularity they attract more attention from would-be attackers – especially since, as we see in the example analysis above, the techniques and understanding needed to do so may be much the same as those used against other platforms. And even though an operating system may include many risk-reducing mitigation technologies, any machine’s defenses against vulnerabilities are directly related to how current its security updates for applications are kept.

If you’re using Microsoft Office 2004 for Mac, Microsoft Office 2008 for Mac or Open XML File Format Converter for Mac, be sure to update using the latest product updates. For this specific vulnerability, you can visit the Microsoft Security Bulletin MS09-027 page and download the update.

Jeong Wook (Matt) Oh
MMPC

 

Categories: exploits, MS09-027, OSX Tags:

Issue with TMG remote SQL logging

April 30th, 2012 No comments

We recently received a case from a customer reporting that the TMG log data were not being properly stored in a remote SQL database but was accumulated in the Large Logging Queue (LLQ).

The LLQ is an improvement added in TMG, particularly useful in scenarios where logging to a remote SQL Server is involved.
This feature allow the logging to continue even if the database is unavailable: log data is stored in a local folder and will be replayed to the database once it becomes available again.
You can read more of this feature here: http://technet.microsoft.com/en-us/library/dd183731.aspx

In the case of our customer the database was available but TMG was logging to LLQ for some reason.
The alert we were getting on the console was:

Forefront TMG failed to connect to SQL Server for Forefront TMG Web filter logging. This failure may be due to a temporary condition, low resources, or inadequate permissions. SQL Server error description: Invalid or unknown table specified.

Connecting to SQL Server will be retried periodically. Until a connection is established, log records will be saved in a log queue on the disk on the local computer. Forefront TMG will continue to operate normally, but the log records in the log queue will not be available in the Forefront TMG log viewer. After a connection to SQL Server is established, the log records in the log queue will be moved to SQL Server and will be available in the log viewer.

The failure is due to error: Invalid or unknown table specified.

The status of the LLQ was particularly concerning, with several GB of data waiting to be committed to the database:

clip_image002

The error suggested Invalid or unknown table so we first checked the configured tables and their structure.
From the TMG console in Logs and reporting we have the current configuration:

clip_image003

Checking in SQL Server we have the tables with the expected names:

clip_image004

Next we checked the table structures.
The table definition files (fwsrv.sql and w3proxy.sql) are in the TMG installation directory which normally can be found in “C:\Program Files\Microsoft Forefront Threat Management Gateway”.

The structure of the current table in the database can also be exported to a text file from the SQL Server Management Studio interface:

clip_image006

Comparing the reference and the current table we found that the customer had added another column in the WebProxyLog table.
The extra column was supposed to cause no harm but in the internal tracing we found that TMG detects a different structure, not matching with any of the supported schemas, and therefore refuses to log into that table.

After removing the extra column the data from the LLQ were properly written to the database and everything resumed working correctly.

 

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

Reviewer:
Lars Bentzen
Escalation Engineer – Microsoft CSS Forefront Security Edge Team

Categories: Logging, TMG Tags:

Best Practice for Configuring Certificate Template Cryptography

April 28th, 2012 No comments

Starting with Windows Vista and Windows Server 2008, the option to utilize Key Storage Providers (KSPs) in addition to Cryptographic Service Providers (CSPs) was added. These options are available when you create a Certificate Template and configure the settings in the Cryptography tab. Depending on the template duplicated, you may see that the default option is Request can use any provider available on the subject’s computer. However, the best practice is to select Requests must use one of the following providers. Then, ensure you configure only the providers that you want to be used. Another best practice is to use a key size of 1024 bits or higher.

More about this topic is on the TechNet Wiki http://social.technet.microsoft.com/wiki/contents/articles/10192.a-certificate-could-not-be-created-a-private-key-could-not-be-created.aspx

Best Practice for Configuring Certificate Template Cryptography

April 28th, 2012 No comments

Starting with Windows Vista and Windows Server 2008, the option to utilize Key Storage Providers (KSPs) in addition to Cryptographic Service Providers (CSPs) was added. These options are available when you create a Certificate Template and configure the settings in the Cryptography tab. Depending on the template duplicated, you may see that the default option is Request can use any provider available on the subject’s computer. However, the best practice is to select Requests must use one of the following providers. Then, ensure you configure only the providers that you want to be used. Another best practice is to use a key size of 1024 bits or higher.

More about this topic is on the TechNet Wiki http://social.technet.microsoft.com/wiki/contents/articles/10192.a-certificate-could-not-be-created-a-private-key-could-not-be-created.aspx

A tangled web…

April 27th, 2012 No comments

The moment of infection, and the circumstances that lead to the introduction of malware to a system, are often not obvious. This short case study examines our observations and investigations into a particular example that illustrates a fairly typical method of compromise that is played out countless times each day​ all over the web.

A couple of days ago, our attention was drawn to a website that appeared to use the Microsoft brand. We received reports that a website with the word “Microsoft” in big friendly letters at the top of the page, may have been serving malware. We were worried that users may visit the site with confidence and trust its content because it carried our name. So, we took a closer look at this “Microsoft” website.

MSPinoy

We can see it does use the title “MSPinoy – Microsoft Philippines Users Group”, and when you click on the Forums tab up top, it sends you directly to an actual Microsoft website. Everything goes well initially, but after less than a minute, the system becomes sluggish and Microsoft Security Essentials reports a possible malware infection.

So the question is: who is “MSPinoy”? After some searching, we found out that the website has existed since June 2008 and has a legitimate registration contact in the Philippines. Based on our research, we assume that this website is probably not malicious, but is a community users group which references some official Philippines Microsoft links for its users.

So, if the site is a real users group (if not Microsoft endorsed per se), then how are visitors getting infected? When we looked further into the webpage source a suspicious iframe emerges at the end of the page. This iframe, which referenced a different host (rvideos.info), soon redirected to another one. Upon being redirected the new webpage contained several malicious Java applets that tried to exploit vulnerabilities on the system and download other malware. When we visited, these exploits were detected as variants of Exploit:Java/CVE-2010-0840 (example file SHA1s observed 626D495992C77BE9E47A9F2A1ED573739F34636F and A67C7CC6BD6C516D865C8BB37134F457E0B89A3D) and Exploit:Java/CVE-2012-0507 (example SHA1 of file observed 374F8FDB2EB49D5C883785A6ED627BE6CF9BACC9).

We also then did an online search into rvideos.info:

MSPinoy

Looks like the registrant is from Australia and belongs to an organization called Privacyprotect.org. The registration date is just a couple of days ago. We continued to monitor this website and found that the malicious iframe was refreshed every day with a different host (such as charming-cuties.com or hpicture.info) which was also registered to Privacyprotect.org.

So, it looks like the MSPinoy website we investigated had been compromised, and the hijack code is being refreshed daily, presumably from a C&C server.

So, our last question: Who is Privacyprotect.org? According to their website, Privacyprotect.org is a company that provides a privacy protection service for domain owners, so that their registration contact details are not generally available to the public. So the true identity behind these domains is still a mystery.

As stated, this short case study is a fairly typical illustration of how malware is distributed, and it teaches some valuable lessons about how to defend yourself:

  • Use a complete AV solution (such as Microsoft Security Essentials)
  • Update your AV daily. As this example shows, the bad guys update their code daily, so you need to as well.
  • Get and install the latest updates for ALL of your computer programs. Be proactive – this is really important.
  • Be vigilant. Bad guys will attempt to take advantage of your existing trusted relationships (such as the relationship you might have with a company like Microsoft).
  • Be aware that these types of attack are prevalent and dangerous and that attackers will try to take advantage of you, your computer and your assets. Use caution online.

Tim Liu
MMPC

 

Categories: CVE-2010-0840, CVE-2012-0507, exploits Tags:

Here’s to the first release from MS Open Tech: Redis on Windows

April 26th, 2012 No comments

The past few weeks have been very busy in our offices as we announced the creation of Microsoft Open Technologies, Inc. Now that the dust has settled it’s time for us to resume our regular cadence in releasing code, and we are happy to share with you the very first deliverable from our new company: a new and significant iteration of our work on Redis on Windows, the open-source, networked, in-memory, key-value data store.

The major improvements in this latest version involve the process of saving data on disk. Redis on Linux uses an OS feature called Fork/Copy On Write. This feature is not available on Windows, so we had to find a way to be able to mimic the same behavior without changing completely the save on disk process so as to avoid any future integration issues with the Redis code.

The version we released today implements the Copy On Write process at the application level: instead of relying on the OS we added code to Redis so that some data structures are duplicated in such a way that Redis can still serve requests from clients while saving data on disk (thus achieving the same effect of Fork/Copy On Write does automatically on Linux).

You can find the code for this new version on the new MS Open Tech repository in GitHub, which is currently the place to work on the Windows version of Redis as per guidance from Salvatore Sanfilippo, the original author of the project. We will also continue working with the community to create a solid Windows port.

We consider this not to be production ready code, but a solid code base to be shared with the community to solicit feedback: as such, while we pursue stabilization, we are keeping the older version as default/stable on the GitHub repository. To try out the new code, please go to the bksavecow branch.

In the next few weeks we plan to extensively test the code so that developers can use it for more serious testing. In the meantime, we will keep looking at the ‘save on disk’ process to find out if there are other opportunities to make the code perform even better. We will promote the bksavecow branch to master as soon as we (and you!) are confident the code is stable.

Please send your feedback, file suggestions and issues to our GitHub repository. We look forward to further iterations and to working with the Redis community at large to make the Windows experience even better.

Claudio Caldato

Principal Program Manager

Microsoft Open Technologies, Inc.

A subsidiary of Microsoft Corporation.

 

More news from MS Open Tech: announcing the open source Metro style theme for jQuery Mobile

April 26th, 2012 No comments

Starting today, the Metro style theme for JQuery Mobile, the popular open source mobile user interface framework, is available for download on GitHub and can be used as a NuGet package in Visual Studio.

The theme enables HTML5 pages to adapt automatically to the Metro design style when rendered on Windows Phone 7.5. The Metro style theme is open source and available for download here. This new Metro style theme’s development was sponsored by Microsoft Open Technologies, Inc. working closely with Sergei Grebnov, an Apache Cordova committer and jQuery Mobile developer.

The theme looks just gorgeous, doesn’t it?

clip_image002_thumb1 clip_image002 clip_image006_thumb1image_thumb1

The CSS and Javascript theme adapts to the current theme used in Windows Phone and applies the right styling to the jQuery Mobile controls.This allows mobile HTML5 web sites and hybrid applications to naturally integrate into the Windows Phone Metro style experience. This offers developers the choice of rapidly integrating the theme into their existing application but also to contribute to this open source project through GitHub.

You can see an extensive demo of the theme on this page and you can learn more on this site where we are publishing new articles, references and source code sample for developing with Apache Cordova and the Metro style theme for jQuery Mobile.

This is another milestone in our continuous engagement with the community. Our team has been working closely with the Windows Phone division to support the mobile HTML5 and JavaScript open source communities over the last year to bring popular open source projects to Windows Phone:

  • A few months ago, we sponsored the development of full Windows Phone support for PhoneGap (now Apache Cordova), the open source framework that lets applications be built for iOS, Android, Windows Phone and other mobile platforms using HTML5, CSS and JavaScript.
  • At the same time significant improvements were brought to jQuery Mobile (read more about this in our previous blog post): feedback from the community has been great and was partly responsible for our decision to expand our engagement with jQuery Mobile and sponsor this work.

We believe it is important for developers to have choices when targeting Windows Phone, and we also want them to be able to deliver a good experience to the users of their applications, especially when making the choice of using Web standards (HTML5, CSS and JavaScript) to target multiple mobile platforms by picking solutions such as Apache Cordova.

To do so, developers already enjoy a selection of Apache Cordova Plugins that give their application a Windows Phone touch such as Social Share, Bing Map launcher and Live Tile. Now developers can use the new open source Metro style theme for jQuery Mobile to give their mobile apps and websites the Metro style look and feel, and offer the final users an experience similar to the one they get with native applications.

As usual we are very interested in hearing from developers and gathering feedback about the experience of developing HTML5-based applications and websites on Windows Phone. Let us know what other features, tools and frameworks you’d like to see.

Abu Obeida Bakhach
Program Manager
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

Categories: Uncategorized Tags:

Help, I’ve been hacked!

April 26th, 2012 No comments

A reader named Karen asks:

“I received a message in my Hotmail inbox that said that I’d been hacked and I should change my password. How do I do this?”

If you think your Hotmail account has been hacked, go to the Reset your password page.

Karen didn’t say whether the message appeared to be from Microsoft or if it was from a friend who received an email from her that looked suspicious (a sign that your account might have been hacked.)

If you receive an email about the security of your account, this could be a scam. Don’t click links in any emails unless you trust the sender. Instead, reset your password.

Get more security tips for Hotmail and learn how to help protect yourself from email and web scams.

MS12-027 – Critical : Vulnerability in Windows Common Controls Could Allow Remote Code Execution (2664258) – Version: 2.0

Severity Rating: Critical
Revision Note: V2.0 (April 26, 2012): Added Service Pack 1 versions of SQL Server 2008 R2 to the Affected Software and added an entry to the update FAQ to explain which SQL Server 2000 update to use based on version ranges. These are informational changes only. There were no changes to the security update files or detection logic. For a complete list of changes, see the entry to the section, Frequently Asked Questions (FAQ) Related to This Security Update.
Summary: This security update resolves a privately disclosed vulnerability in Windows common controls. The vulnerability could allow remote code execution if a user visits a website containing specially crafted content designed to exploit the vulnerability. In all cases, however, an attacker would have no way to force users to visit such a website. Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that takes them to the attacker’s website. The malicious file could be sent as an email attachment as well, but the attacker would have to convince the user to open the attachment in order to exploit the vulnerability.

Categories: Uncategorized Tags:

Summary for April 2012 – Version: 2.0

Revision Note: V2.0 (April 26, 2012): For MS12-027, added Service Pack 1 versions of SQL Server 2008 R2 to the Affected Software and clarified the Affected Software to show that the update applies to all installations of Microsoft SQL Server 2000 Analysis Services Service Pack 4, as the QFE and GDR distinction does not apply to this product. These are informational changes only. There were no changes to the security update files or detection logic. Because the updates have been offered correctly since initial release, customers who have already successfully installed the updates do not need to take any action.
Summary: This bulletin summary lists security bulletins released for April 2012.

Categories: Uncategorized Tags:

SIRv12: The obstinacy of Conficker

April 25th, 2012 No comments

Conficker is one of the most significant threat families facing organizations worldwide today; its initial impact along with its continued obstinacy shows that clearly. In the fourth quarter of 2011 – three years after its initial release – it attempted to infect just over 1.7 million computers. Conficker’s persistence is illustrated not only by the number of computers it has attempted to infect, but also by the nearly 59 million attacks launched against those computers in the fourth quarter of 2011. But perhaps the most interesting manifestation of its obstinacy is that it has been the number one threat facing businesses for the past two and a half years.

Conficker affects a higher percentage of business computers than consumer computers

Figure 1. Conficker affects a higher percentage of business computers than consumer computers

The nature of how later Conficker variants spread is the key to understanding what makes the worm so much more of an issue for businesses than for consumer users. Initially the worm spread through the Internet solely by exploiting a software vulnerability in the Windows Server service that had been addressed months earlier in Microsoft Security Bulletin MS08-067. About one month later, Conficker was updated to spread using the Autorun feature and weak passwords or stolen login tokens. The use of weak passwords and stolen login tokens was the change that gave it a foothold in the business sector environment.

Once later variants of Conficker infect a computer, they attempt to spread by copying themselves into administrative shares of other computers on the network. First the malware tries to use the current user’s credentials to copy itself, but if that fails it attempts to exploit weak passwords; the worm uses a pre-existing list of common weak passwords that it carries with it. If that fails, Conficker remains dormant until new credentials are available. If a remote administrator logs into the infected computer to try to clean it or diagnose problems caused by the worm, Conficker uses the administrator’s login token to infect as many computers as possible. The combination of these credential-based attacks accounted for 100% of all recent infection attempts from Conficker targeting Enterprise Microsoft Forefront Endpoint Protection users on Windows 7 and Windows Vista platforms.

How Conficker spreads through corporate networks

Figure 2. How Conficker spreads through corporate networks

Despite Microsoft removing Conficker from approximately 283,000 computers per quarter on average for the past year, the worm continues to be persistent. As an illustration of this, the average number of attacks per system throughout 2011 is on the rise. During the first quarter of 2011 the average number of times Conficker attacked a single computer was 15, but by the fourth quarter that number had more than doubled to 35.

The average number of Conficker attacks per system is on the rise

Figure 3. The average number of Conficker attacks per system is on the rise

One of the primary ways to defend against Conficker is by enforcing a strong password policy. A single computer with a weak password could easily be enough to cause a major disruption inside a corporate network, especially considering the increasing trend in the number of Conficker attacks per computer. If the worm does get inside a network, a good guide to cleaning it out can be found in the How-to: Removal of Conficker in your FCS environment blog post. Along with strong passwords, it is important to keep systems up to date by regularly applying available updates for all software being used and to use antivirus software from a trusted source, and make sure AV signatures are regularly updated.

You can find more information there on the obstinacy of Conficker in our latest Microsoft Security Intelligence Report volume 12 that launched today, as well as other global and regional trends in Internet security.
 
– Joe Blackbird, MMPC

 

Categories: conficker, MS08-067, SIR v12, weak passwords Tags:

MS12-028 – Important : Vulnerability in Microsoft Office Could Allow Remote Code Execution (2639185) – Version: 1.1

Severity Rating: Important
Revision Note: V1.1 (April 25, 2012): Added an entry to the update FAQ to explain why this update is offered to customers running Microsoft Office 2007 Service Pack 3.
Summary: This security update resolves a privately reported vulnerability in Microsoft Office and Microsoft Works. The vulnerability could allow remote code execution if a user opens a specially crafted Works file. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Categories: Uncategorized Tags:

SSO (Single Sign On) not working for a published Web Application with UAG

April 24th, 2012 No comments

Toolbox3Introduction:

We had an application published on Microsoft Forefront Unified Access Gateway 2010 (UAG). Single Sign On (SSO) for that particular application on UAG was not working. We were using 401 to delegate credentials on the Applications Publishing Rule on UAG.

Scenario:

The issue was specific to one particular application published through UAG. SSO for the other published applications was working fine, so there was definitely something different on that particular server.

The users were getting the following error when trying to access the application externally:

You do not have permissions to view this folder or page

Troubleshooting:

We gathered a UAG trace and its analysis showed the following errors:

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CSSPINegStep::ProcessNegStep HTTP401Authentication.cpp@1340] ERROR:HTTPAuth::CSSPINegStep::ProcessNegStep – ERROR: InitializeSecurityContext failed with error code 0x80090302 (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10)

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CNTLMHandler::Negotiate HTTP401Authentication.cpp@1515] ERROR:HTTPAuth::CNTLMHandler::Negotiate – conversation failed, resetting state (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10

Error Code 0x80090302 resolves to SEC_E_UNSUPPORTED_FUNCTION.

Researching the message led us to an article on TechNet that stated:

According to InitializeSecurityContext (NTLM) documentation, a call to this method will return a SEC_E_UNSUPPORTED_FUNCTION when : A context attribute flag that is not valid (ISC_REQ_DELEGATE or ISC_REQ_PROMPT_FOR_CREDS) was specified in the fContextReq parameter.

Network traces confirmed that it was exactly the behavior mentioned above, as the backend web server was not setting the "128-Bit Encryption" flag on its reply in the NTLM negotiate header. In a Network Monitor capture, this is what that looks like:

Request sent from UAG to the web server:

clip_image002

Response from the web server:

clip_image004

As it turns out, the backend server does not support 128-bit NTLM encryption, but UAG was set to require it.

The ideal way to solve this is by configuring the backend server. If, however, the backend server cannot support 128-bit, we can work around this by disabling 128-bit in UAG. Disabling 128-bit on the UAG server should only be done as a last resort. This is the procedure:

1. Open the local group policy editor on the UAG server

2. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

3. Double-click the option “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers":

clip_image006

4. Uncheck both options and click OK. The setting will change to read “no minimum”:

clip_image008

5. Exit the group policy editor.

 

Author:

Nitin Singh
Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Ophir Polotsky
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Ben Ari
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Categories: Uncategorized Tags:

SSO (Single Sign On) not working for a published Web Application with UAG

April 24th, 2012 No comments

Toolbox3Introduction:

We had an application published on Microsoft Forefront Unified Access Gateway 2010 (UAG). Single Sign On (SSO) for that particular application on UAG was not working. We were using 401 to delegate credentials on the Applications Publishing Rule on UAG.

Scenario:

The issue was specific to one particular application published through UAG. SSO for the other published applications was working fine, so there was definitely something different on that particular server.

The users were getting the following error when trying to access the application externally:

You do not have permissions to view this folder or page

Troubleshooting:

We gathered a UAG trace and its analysis showed the following errors:

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CSSPINegStep::ProcessNegStep HTTP401Authentication.cpp@1340] ERROR:HTTPAuth::CSSPINegStep::ProcessNegStep – ERROR: InitializeSecurityContext failed with error code 0x80090302 (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10)

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CNTLMHandler::Negotiate HTTP401Authentication.cpp@1515] ERROR:HTTPAuth::CNTLMHandler::Negotiate – conversation failed, resetting state (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10

Error Code 0x80090302 resolves to SEC_E_UNSUPPORTED_FUNCTION.

Researching the message led us to an article on TechNet that stated:

According to InitializeSecurityContext (NTLM) documentation, a call to this method will return a SEC_E_UNSUPPORTED_FUNCTION when : A context attribute flag that is not valid (ISC_REQ_DELEGATE or ISC_REQ_PROMPT_FOR_CREDS) was specified in the fContextReq parameter.

Network traces confirmed that it was exactly the behavior mentioned above, as the backend web server was not setting the "128-Bit Encryption" flag on its reply in the NTLM negotiate header. In a Network Monitor capture, this is what that looks like:

Request sent from UAG to the web server:

clip_image002

Response from the web server:

clip_image004

As it turns out, the backend server does not support 128-bit NTLM encryption, but UAG was set to require it.

The ideal way to solve this is by configuring the backend server. If, however, the backend server cannot support 128-bit, we can work around this by disabling 128-bit in UAG. Disabling 128-bit on the UAG server should only be done as a last resort. This is the procedure:

1. Open the local group policy editor on the UAG server

2. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

3. Double-click the option “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers":

clip_image006

4. Uncheck both options and click OK. The setting will change to read “no minimum”:

clip_image008

5. Exit the group policy editor.

 

Author:

Nitin Singh
Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Ophir Polotsky
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Ben Ari
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Categories: Uncategorized Tags:

Help mom stay safer online

April 24th, 2012 No comments

Maybe she wants flowers, but a more practical gift this mother’s day might be to make sure your mom knows some basic rules about keeping your computer updated and creating strong passwords.

Read our six basic online safety tips.

You can also download the tips in an easy-to-print card for mom.

Since these tips are free, consider springing for the flowers too. Or how about a new Windows Phone?

Categories: online safety, passwords, security, Tips Tags:

Another Behavior of the TEST RULE Button in Threat Management Gateway 2010

April 24th, 2012 No comments

 

Introduction:

Recently, I worked on a case where we were publishing Exchange CAS (Client Access Servers) servers on TMG. We were seeing some unexpected behavior while using KCD (Kerberos Constrained Delegation) as the Authentication Delegation Method and using a Web Farm in the Publishing Rule.

The Scenario was like this.

We were publishing the target CAS servers as a Web Farm and using KCD as the Delegation method. Therefore, the SPN specified on Authentication Delegation was “http/*”.

But when we were using TEST RULE Button to Test this, we were getting the Following Error:

Category: KCD error


Error details: There is no suitable Service Principal Name (SPN) entry found for this Forefront TMG computer in Active Directory.
Action: Kerberos Constrained Delegation requires the Forefront TMG computer to be trusted for delegation for any authentication protocol and the Service Principal Name (SPN) used by Forefront TMG must be added to Active Directory

However, when we tried to Access Exchange Services like OWA, Active Sync etc. externally, everything worked just fine.

So, that made us believe that there is something wrong with the TEST RULE Button here in this case.

Further Troubleshooting:

Then we tried to put the SPN with the name of one of the CAS servers in the Authentication Delegation Tab. And now when we ran the TEST RULE again it was Successful.

While researching the issue further, we discovered that this behavior is a known issue that is currently under investigation.

CONCLUSION:

If you are publishing a Web Farm using KCD as the Delegation method, and find that using the “Test Rule” button gives the above error, try testing connectivity/authentication from an external client.
As the “Test Rule” button may not be a reliable test with this publishing scenario, you should test using an external client.

Author

Nitin Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Richard Barker

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Categories: Uncategorized Tags:

Analysis of the Eleonore exploit pack shellcode

April 20th, 2012 No comments

‘​Eleonore‘ is a malware package that contains a collection of exploits used to compromise web pages. When the compromised web pages are viewed via vulnerable systems, the exploit payload is run. Eleonore is purchased by an attacker from an underground website. The attacker then gains access to Internet web servers and installs the exploit by modifying webpages, which are then served to the public. The malware pack also contains functionality for the tracking and management of compromised computers.

Remote attacker purchases the exploit pack, installs Eleonore (courtesy of MMPC)

Image 1 – Remote attacker purchases the exploit pack, retrieves web pages from Internet servers and installs Eleonore

Eleonore is developed and released as version updates. This blog post focuses on the shellcode exploit from one of the releases, version 1.2. At a high level, the Eleonore shellcode locates kernel32.dll in an exploited process space. It uses the spatially efficient hash lookup to find the absolute address of key Kernel32 APIs:


Image 2 – FindFuncHash routine

With access to these functions, the shellcode creates a file in the temporary files folder (%TEMP%) and calls URLDownloadToFile with a URL that is 0x67 bytes after the shellcode. The shellcode then executes that file.

The exact URL is dependent on bytes included in the exploit payload and is beyond the scope of this analysis. The exploit then decrypts bytes right after the shellcode for another URL and calls URLDownloadToFile for a second time, copying the file from a URL such as the following:

<website domain with Eleonore installation>/path/getexe.php

This URL was obtained by looking at the entire exploit payload from an Eleonore installation – that data is not included in this article. The “getexe.php” file creates a server-side response that returns a file named “load.exe“. The contents of this file are put into a secondary file, decrypted in memory, written back to the file and finally executed.

Decrypt routine

Image 3 – DecryptBytes routine

 

The shellcode ends here as “load.exe” begins, with the affected computer now compromised.

Eleonore v1.2 contained numerous exploits and attack code that targets several programs including:

  • DirectX 9, affecting certain versions of Windows operating system
    • Vulnerability discussed in CVE-2008-0015 and
      fixed with Microsoft Security Bulletin MS09-032
    • Malware detected as Exploit:JS/CVE-2008-0015 and Exploit:HTML/CVE-2008-0015
  • Microsoft Internet Explorer 7 memory corruption
    • Vulnerability discussed in CVE-2009-0075 and
      fixed with Microsoft Security Bulletin MS09-002
    • Malware detected as Exploit:JS/CVE-2009-0075
  • Microsoft Internet Explorer ActiveX control “snpvw.Snapshot viewer Control.1”
    • Vulnerability discussed in CVE-2008-2463 and
      fixed with Microsoft Security Bulletin MS08-041
    • Malware detected as Exploit:JS/Objsnapt.E, Exploit:JS/Objsnapt.F and Exploit:HTML/Snavic.gen!D
  • Microsoft Internet Explorer 6 MDAC
    • Multiple vulnerabilities, discussed in CVE-2004-0549 and CVE-2006-0003, and
      fixed with Microsoft Security Bulletin MS04-025 and MS06-014
    • Malware detected as TrojanDownloader:VBS.Psyme.X, TrojanDownloader:JS/Adodb (and other names)
  • Opera telnet 9.25
  • Certain versions of Mozilla Firefox
  • Certain versions of Adobe Reader

To protect against Eleonore and other threats, the MMPC recommends maintaining security updates across all products, not only those serviced by Microsoft Windows updates, and using security software with active scanning enabled.

 

— Nik Livic & Patrick Nolan, MMPC

 

Can digital picture frames and thumb drives spread viruses?

April 20th, 2012 No comments

We recently received an email from a concerned reader who’d heard that digital picture frames might contain viruses. While this is not a common problem, the truth is that anything that you plug into your computer and use to transfer files onto your computer , whether it’s a digital picture frame, a USB drive (also called a “thumb drive” or a “flash drive”), or even your own smartphone, can contain viruses.

Here are a few tips to avoid viruses from external devices that you plug into your computer:

Install Microsoft Security Essentials. Microsoft Security Essentials is popular antivirus software that you can download for free. When you transfer files onto your computer from any device, Microsoft Security Essentials will scan the files automatically.

Use external devices with caution. Don’t put an unknown flash (or thumb) drive into your PC. Even if you trust the owner of the drive, don’t open files that you weren’t expecting.

Use the Microsoft Safety Scanner. If you think you might have already downloaded an infected file from a digital picture frame or other external drive, use the free Microsoft Safety Scanner to check your PC.

For more information about how to boost your malware defense and protect your PC.

 

 

 

Mac OS Clients fail to access SSL Websites after you enable HTTPS Inspection in Forefront TMG 2010

April 20th, 2012 No comments

The concept of HTTPS Inspection (referred to HTTPSi later) was covered in a previous blog article by Yuri Diogenes, which also contains helpful formation about common issues that may occur. If you have missed it, you can find it here.

This current article is intended to explain the root cause of a specific issue and how to solve this.
The issue is: Mac OS clients are not able to use a certificate which is created by Microsoft Forefront TMG 2010 for HTTPSi when using the option “Use Forefront TMG to automatically generate a certificate”.

image

See the following TechNet Article which provides more information on this process: http://technet.microsoft.com/en-us/library/dd441053.aspx

When analyzing this issue, we found that the issue is connected to the fact that TMG uses Unicode and not ASCII to create these certificates. If you take a look at the details of the certificate, you can see that the Subject and Issuer fields for a Certification Authority created certificate are CERT_RDN_PRINTABLE_STRING (ASCII), whilst in the certificate generated by TMG the above fields are CERT_RDN_UNICODE_STRING.

TMG is only able to create a UNICODE certificate when issuing a self-signed certificate for HTTPSi. However, Microsoft completely sticks to the RFC 3280 by using UNICODE.
http://www.ietf.org/rfc/rfc3280.txt
Here is some more information on UTF-8 which is used:
http://en.wikipedia.org/wiki/UTF-8
http://msdn.microsoft.com/en-us/library/aa377501(VS.85).aspx

You can display this certificate’s details if you use the following syntax: ‘certutil –verify –v certname.cer’
Analyzing the output, you can see the following properties:

Issuer:

CN=Microsoft Forefront TMG HTTPS Inspection Certification Authority

[0,0]: CERT_RDN_UNICODE_STRING, Length = 128 (64/64 Characters)

2.5.4.3 Common Name (CN)=”Microsoft Forefront TMG HTTPS Inspection Certi

fication Authority”

Subject:

CN=Microsoft Forefront TMG HTTPS Inspection Certification Authority

[0,0]: CERT_RDN_UNICODE_STRING, Length = 128 (64/64 Characters)

2.5.4.3 Common Name (CN)=”Microsoft Forefront TMG HTTPS Inspection Certi

fication Authority”

If you compare this to a certificate issued by a Certification Authority, it looks like this:

[2,0]: CERT_RDN_PRINTABLE_STRING, Length = 13 (13/64 Characters)

2.5.4.3 Common Name (CN)=”DCTMGNETZ1-CA”

Subject:

CN=A2-EE-DOM-1.TMGNETZ.LOCAL

[0,0]: CERT_RDN_PRINTABLE_STRING, Length = 25 (25/64 Characters)

2.5.4.3 Common Name (CN)=”A2-EE-DOM-1.TMGNETZ.LOCAL”

Solution:
As described, TMG is 100% RFC compliant in this case. However, you are able to issue a certificate from a Windows Server 2003 or Windows Server 2008 (R2) Certification Authority which can be handled by Mac clients.

The following screenshots are intended to provide assistance on how to enroll for a Subordinate CA certificate using a Windows Server CA and how to install it in TMG 2010.

Connect to the Certification Authority and open the CA MMC.
First you will need to duplicate the existing template for a Subordinate CA and edit the properties before you are going to publish that new template.

image

image

image

image

image

image

image

image

image

image

image

Then you must grant the permissions to enroll. Open the Security tab and click on Add. Click on Object Types to be able to choose from computer accounts, too.

image

In this example I am granting the enroll permission to both the DC DCTMGNETZ1 and my TMG server A2-EE-DOM-1. If your TMG server does have connectivity to the CA, you can enroll for this certificate using the TMG server itself. If this is not the case, you could also create it on the CA first using this permission example.

image

Then please click on OK to save the template.
Now you will need to issue this certificate template before you enroll for a certificate

image

image

After you have clicked on OK, you are ready to enroll for this certificate. There are multiple ways to do this. One of them is to use the tool certreq.exe. Using certreq.exe to achieve this is pretty similar to the procedure described in the following two articles:
http://blogs.technet.com/b/pki/archive/2009/08/05/how-to-create-a-web-server-ssl-certificate-manually.aspx

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

Assuming you might be inexperienced in this area, I am going to show you how to do this using GUI tools.

Assuming TMG is a domain member and has connectivity to the CA, open a MMC on the TMG server by clicking on Start and then type MMC. In the new MMC window, click on File > Add/Remove Snap-in > Choose ‘Certificates’ from the available snap-ins > Add > Choose ‘Computer Account’ and click on Finish.

After you have expanded the list, right-click on Certificates (Local Computer)\Personal\Certificates and choose ‘Request New Certificate” as shown below.

image

After you have clicked through the first two screens, you will hit the list of certificate templates which you are eligible to enroll for. Navigate to the name of the created template and click on “Click here to configure settings”. This is necessary to enter required information manually, like the Common Name for example.

image

image

If you want to be able to archive the private key afterwards, you will need to switch to the ‘Private Key’ tab and check this option.

image

After you complete this wizard, you should receive a confirmation that the certificate has been enrolled.

image

Back in the MMC, right click on the new certificate and choose All Tasks > Export

image

In the new wizard, choose ‘Yes, export the private key’ and click on next > optionally choose one of the options and click on Next > type a password > Next > Choose a path and filename (e.g. c:\certificate.pfx) for the exported certificate.

Now we are ready to import this certificate into TMG for HTTPSi. Open the Forefront TMG MMC, navigate to Web Access Policy in the left pane > click on ‘Configure HTTPS Inspection’ in the tasks pane which will take you to the following screen. Choose ‘Import a certificate’.

image

Browse to the pfx file you exported before and enter the password you chose. This is it. After you have applied the configuration in TMG, you are ready. You can verify the installed certificate to double-check everything by clicking on ‘HTTPS Inspection Trusted Root CA Certificate Options’ and ‘View Certificate Details…’.

The next screen is intended to illustrate that the created custom template was used to issue to the certificate to the TMG Server.

Assuming that the CA is already trusted by your clients, you don’t need to add anything for your clients. Otherwise you would need to install/deploy the CA Server’s root certificate into the Trusted Root CA’s store of your HTTPSi clients. Coming back to the MAC clients, the following article might be helpful to you:
How to install a trusted root CA certificate and an intermediate CA certificate on a computer that is running Microsoft Entourage 2004 for Mac on a Mac OS X 10.3 or a Mac OS X 10.2 operating system
http://support.microsoft.com/kb/887413

I hope this article explains the background information for this issue and how to work around it for if you need to use Mac clients. I am looking forward to your comments.

Author:
Frank Hennemann
Microsoft CSS Forefront Security Edge Team

Reviewer:
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Categories: Uncategorized Tags:

Revenge of the Reveton

April 19th, 2012 No comments

Computer users around the world are increasingly accustomed to managing their bank accounts, paying their bills and performing other activities online. The use of technology to manage finances has long been a target of attackers, and malware authors continue to create scams that try to persuade potential victims to provide access to their valuable personal information, including logon credentials for online accounts. Trojan:Win32/Reveton.A is a recent example of malware that attempts to phish these details from victims using the great motivator – fear.

Trojan:Win32/Reveton.A displays a warning that alleges that the affected computer has accessed “pornographic content, elements of violence and child pornography.” The message also suggests that the computer has been “locked” and that the user is “obliged to pay a fine to unlock“, as shown below:

 Reveton ransom

This phishing and ransom message is also detected by MMPC as Trojan:HTML/Ransom.A. The scam in this attack attempts to phish user accounts for the electronic payment services Ukash and Paysafecard. We wrote about this type of ransom attack in a previous blog post.

Account information provided by the user is stolen and sent to a remote server at “91.195.254.86”. Indications are that this allocated server IP address may be physically located in Russia:

inetnum: 91.195.254.0 – 91.195.255.255
netname: GEOSYSTEM-NAVIGATION-NET
description: ZAO GeoSystem Navigation
country: RU

If you’ve been a victim of this scam, or similar, review these steps to take, to minimize your financial loss and/or damage to your identity.

As always, we advise you to be cautious when providing sensitive personal information, such as electronic account details, as it could lead to identity or financial theft.

Patrick Estavillo, MMPC

Categories: Uncategorized Tags: