Archive

Archive for May, 2012

Don’t click text message spam

May 31st, 2012 No comments

Several readers have contacted us lately about suspicious text messages that they’ve received on their smart phones.

Some of these messages appear to be from Microsoft, Starbucks, Best Buy, or other well-known companies and are designed to trick you into clicking links with lures of free gifts or prizes. If you click these links you could be taken to a malicious website that could automatically download malicious software onto your phone. This could cause damage to your phone or could be used to steal your personal information or remotely control your phone.

Don’t click links in text messages unless you know the sender and are expecting the link.

Get more information on how to protect yourself from email and web scams and learn how to help secure your smart phone.

Request File Can’t be Located during CA Certificate Renewal

May 29th, 2012 No comments

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:%1_%3%4.req. I followed these steps to fix this issue:

  1. Start the Registry Editor
  2. Navigate to HKLMSystemCurrentControlSetServicesCertsvcConfiguration<CASanitizedName>
  3. Locate the Registry String RequestFileName
  4. Change the value from a:%1_%3%4.req to C:%1_%3%4.req
  5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

 

Request File Can’t be Located during CA Certificate Renewal

May 29th, 2012 No comments

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:\%1_%3%4.req. I followed these steps to fix this issue:

  1. Start the Registry Editor
  2. Navigate to HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<CASanitizedName>
  3. Locate the Registry String RequestFileName
  4. Change the value from a:\%1_%3%4.req to C:\%1_%3%4.req
  5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

 

Request File Can’t be Located during CA Certificate Renewal

May 29th, 2012 No comments

During my work with a customer renewing their Issuing CA’s certificate based on the steps documented in this article, I discovered that the Request file generated couldn’t be located in the default location of %systemDrive% . The Issuing CA didn’t log any errors in the Event Log, nor did it post any error messages. I also searched for all files with the extension *.req on all drives, and still couldn’t find the file.

After some more research, I discovered that my customer changed the default location of the RequestFileName Registry Key during their installation to a drive that no longer exists on the CA. The location configured was a:\%1_%3%4.req. I followed these steps to fix this issue:

  1. Start the Registry Editor
  2. Navigate to HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\<CASanitizedName>
  3. Locate the Registry String RequestFileName
  4. Change the value from a:\%1_%3%4.req to C:\%1_%3%4.req
  5. Stop and Start the Certification Active Directory Certificate Services service

I was then able to create the Request File and submit it to the Offline Root CA to process it.

 

Protect your PC from the latest threats

May 29th, 2012 No comments

Since the Microsoft Security Intelligence Report was released last month, we’ve been discussing some of the findings here, including research on the Conficker worm and the prevalence of rogue security software called scareware.

Here are three Microsoft tools that can help you protect yourself from these threats and others:

  • Microsoft Security Essentials offers free real-time protection that combines an anti-virus and anti-spyware scanner with phishing and firewall protection.
  • The Microsoft Safety Scanner is a free downloadable security tool that provides on-demand scanning and helps remove malware and other malicious software. The Microsoft Safety Scanner is not a replacement for an up-to-date antivirus solution, because it does not offer real-time protection and cannot prevent a computer from becoming infected.
  • SmartScreen Filter, a feature in Internet Explorer 8 and 9, offers protection against phishing sites and sites that host malware. Microsoft maintains a database of phishing and malware sites reported by users of Internet Explorer and other Microsoft products and services. If you attempt to visit a site in the database with the filter enabled, Internet Explorer displays a warning and blocks navigation to the page.

For more information, see a list of free Microsoft products help protect your computer from malware.

Dishigy dishes out the DDoS and we dig deeper…

May 25th, 2012 No comments

​The May edition of the Microsoft Malicious Software Removal Tool saw the inclusion of two new malware families: Win32/Unruy and Win32/Dishigy. Let’s dig a bit deeper into Dishigy and the nature of Denial of Service.

So, bear with me while I take you back to security 101…

A Denial of Service (DoS) attack is a pretty straightforward concept – an attacker floods or otherwise sends malicious traffic to a targeted system in such a way that the targeted system is not able to respond to legitimate requests. Sometimes, particularly for flood attacks, a single system may not be able to generate enough traffic to flood a target by itself, and so multiple machines are used in order to more effectively ‘flood’ the target and make the attack more difficult to block. This is where we get the term Distributed Denial of Service (DDoS) attack – where the attack is distributed across multiple machines, and those machines are ordered to attack a single target and overwhelm it with their concerted requests.

So, why would an attacker want to stop a system from being able to respond to requests from legitimate users? It’s a fairly common behavior amongst malware, and, like the vast majority of malware created and distributed these days, you just have to ask yourself how criminals could use such nefarious practices to make a buck. In the case of Denial of Service conditions, they could be used, for example, for extortion (i.e. “Do what we want or the website gets it, see?“) or possibly for taking out the competition.

Where does Dishigy fit in? Dishigy traditionally targeted web servers. It uses HTTP requests to perform its denial of service payload against websites. While other types of network traffic might be subject to additional restrictions due to the threat it might pose, port 80 is often left mostly unchecked, enabling easy egress of web traffic. Dishigy is a distributed denial of service attack for hire and can be purchased from the seedier side of the internets to target websites of the purchaser’s choice. Now for the grim, technical details…

Win32/Dishigy is written in Delphi, and can be remotely instructed by an attacker to perform denial of service attacks on targets. The malware connects to a hard-coded remote host and sends an HTTP POST to obtain configuration data. The configuration data contains a set of three parameters separated by a token (delimiter) and is followed by a target URL, as shown in the image below:

Dishigy configuration data with target URL obscured

Image 1 – Dishigy configuration data with target URL obscured

The first parameter defines the type of attack it uses; these can vary depending on what types are supported by each variant (for example, HTTP GET requests or HTTP POST requests).

The second parameter denotes the maximum number of threads (channels of execution) the malware should use in an attack; each thread sends several requests in a loop.

The third parameter is the frequency with which the malware should connect to the remote host to obtain updated configuration information. If, however, there is no target host available in the configuration data, the malware will connect back at the specified frequency but not perform any attacks.

The malware can be instructed to perform one of several types of attacks. The malware uses an open source TCP/IP Winsock library for Delphi called Synapse to construct the packets.

Early variants of Dishigy generated only HTTP GET requests against a target:

Image 2 – Use of HTTP GET request by Dishigy

The User-Agent field is randomly chosen from a large list contained in the malware, this makes it appear that the HTTP requests originate from a variety of sources. Later variants added more functionality, including the ability to generate HTTP POST requests against a target:

The POST request includes a Referer field which is also randomly chosen from a list contained in the malware. Worth noting is that the POST data contains the URL for the targeted host only as opposed to a typical POST which could include form data and other bits.

Dishigy’s addition to the Microsoft Windows Malicious Software Removal Tool this month makes the web a slightly better place. Dishigy’s success against a target relies on numbers, so taking out as many infections as possible that could contribute to a flood is key to making it ineffective. It is also highly resource intensive for the unfortunate victims who find their computers compromised by this menace, so removing it from victim computers should ease some pain for individuals whose computing experience has been affected by this threat. And maybe, most importantly, targeting Dishigy may help to stop criminals from deciding which websites you can and can’t visit.

– Ray Roberts
MMPC Melbourne

Authentication failure while trying to access a website through TMG as forward proxy

 

This post is about an issue I came across while working on a case and thought of sharing with all. It was not a straight forward issue; well a lot of them are not! J , Issue was with a certain website hosted on an external web server, when users in the internal network of TMG server try to access this website through TMG server, they get authentication prompt and after entering the user credentials, user gets page could not be displayed on the browser.

In this scenario the access rule on TMG, required users to authenticate. Customer had another network which was behind ISA server 2004 sp3 and same website for the user was working without issues.

Troubleshooting

After verifying that, all the basic settings were correct on the TMG server. I collected Network monitor on the client and TMG data packager as explained in this link simultaneously, http://blogs.technet.com/b/sooraj-sec/archive/2010/04/10/instructions-for-isa-data-packager-to-collect-data-in-repro-mode.aspx, for working and non-working scenario.

Data Analysis.

In the Network monitor traces taken on the client I saw a weird behavior, shown and discuss below. If we look at following snapshot, we can see few Get Requests/Responses marked. It is a get request for same URL.

clip_image002

If we look into the details of the network traces, After the TCP handshake we see first get request. In response to that we see proxy authentication required message back from the TMG server.

clip_image004

Details of the Proxy authentication message from the TMG server, which is status code 407, proxy authentication required.

clip_image006

Then client responds with credentials using Kerberos token shown below

clip_image008

Then we get reply from the TMG server with http status code 401, authentication required.

clip_image010

This response was actually coming from web server(we confirmed by looking at network traces taken on the external NIC of the TMG server) and TMG server was forwarding to client, that’s how user was getting authentication prompt on his browser. But in network traces we can see this was happening again and again i.e. first TMG sends 407 proxy authentication required and then forwards 401 status code and finally connection gets reset by client. In above 401 messages we can also see that web server who is hosting the web site is using NTLM authentication.

Research and Resolution

Found following explanation

*************************

AuthPersistence Usage in IIS 6.0

In earlier versions of IIS, the AuthPersistence metabase property had three possible settings. Two of the settings allowed administrators to enhance performance by specifying persistence based on the existence of a proxy server. Administrators could use either of those AuthPersistence settings to force IIS to negotiate one-time-per-client connections and then use those credentials for subsequent requests over the same connections. These two settings have been removed from IIS 6.0 for security reasons.

In IIS 6.0, the only valid setting for the AuthPersistence metabase property is AuthPersistSingleRequest, and NTLM is the only IIS 6.0 authentication protocol that honors this setting. The setting for AuthPersistSingleRequest is honored only in the following circumstances:

Integrated Windows authentication is set to NTLM.

Integrated Windows authentication is set to Negotiate, and NTLM authentication is used.

In either of these cases, AuthPersistSingleRequest is False — that is, not set — for backward compatibility with earlier versions of IIS. A value of False means that authentication persists for subsequent requests over the same connection.

In IIS 6.0, all other authentication protocols assume that the value of AuthPersistSingleRequest is True — that is, set — so authentication persists only for a single request over a connection. IIS 6.0 automatically resets authentication at the end of a request and forces each subsequent request over the same connection to authenticate.

From http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8feeaa51-c634-4de3-bfdc-e922d195a45e.mspx?mfr=true

****************************

As per above explanation AuthPersistSingleRequest should be False

( http://msdn.microsoft.com/en-us/library/dd447565.aspx ) in our scenario on TMG server and we can proxy NTLM authentication.

Then checked this property in ISAinfo, we found that customer had set its value to Boolean 1 as shown below on TMG server’s internal network.

clip_image012

This is a com property and we cannot set its value through GUI, We found that customer had imported an xml file to import configuration from another server and this setting was set to 1 in that xml, after changing its value to default 0 in that xml file and importing it again, issue got resolved and we were able to access the website through the TMG server.

As I mentioned in this scenario, customer modified this property unknowingly while importing and we were able to revert that. This property cannot be modified through GUI, so if you encounter similar issue and find this property changed to 1 then change tracking tool can be used to see what changes happened (any imports as discussed here) else engaging MS support would be the right thing to do to get it back to default.

Note: ISAInfo is one of the logs you can collect while collecting TMG data packager data, more about it and TMG data packager can be found in this link http://www.isaserver.org/tutorials/Advanced-Forefront-TMG-debugging.html, in short this log has ISA/TMG configuration information.

Author

Suraj Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team.

Technical Reviewers:

Richard Barker

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Categories: Uncategorized Tags:

A technical analysis of Adobe Flash Player CVE-2012-0779 Vulnerability

May 24th, 2012 No comments

Recently, we’ve seen a few attacks in the wild targeting a patched Adobe Flash Player vulnerability. The vulnerability related to this malware was addressed with a recent patch released by Adobe on May 4th. On the Windows platform, Flash Player 11.2.202.233 and earlier is vulnerable. If you’re using vulnerable version, you need to update your Flash Player now to be protected against these attacks. We had a chance to analyze how the malware (sha1: e32d0545f85ef13ca0d8e24b76a447558614716c) works and here are the interesting details we found during the investigation.

The following diagram shows the overview of the attack flow. The attack is initiated by sending a malicious document that contains a SWF download trigger and a malicious binary. The document doesn’t contain any malicious SWF payload at all.

Figure 1 Overview of the attack

Here is the detailed process that describes how the infection occurs when the victim opens the malicious document:

1) When the user opens the malicious document, the SWF download trigger part of the document downloads external content for rendering. This is specifically crafted to download malicious SWF content from malicious server 1. The embedding feature is not malicious itself, but the downloaded SWF is malicious and abuses the vulnerability in the Adobe Flash Player plugin.

2) The malicious SWF content is downloaded to the user’s application and is rendered. The malicious SWF is a wrapper with the actual payload encoded inside it and is loaded dynamically. We call this dynamically loaded content layer 2 SWF. The layer 2 SWF is loaded and spreads heap spraying code on the target application’s memory space.

3) The vulnerability trigger part of the layer 2 SWF contacts the designated malicious server to retrieve malicious data. This data causes the vulnerability to manifest.

4) The heap spray code loaded by layer 2 SWF is executed when the vulnerability is triggered.

5) The shellcode inside this layer 2 SWF decrypts a PE file from the malicious document. First of all, it enumerates all the opened handles to find the original malicious document – if the enumerated file contains an 8 byte marker at a certain offset then it is found. Then it decrypts the PE file from 0x10 bytes after the found marker. Each byte is XORed with a hard coded key while skipping byte zero and the byte with the same value as” key”. After decryption, the PE file (SHA1: 27c8bdacd4023858a810bec917381c6a7512715e) is detected as TrojanDropper:Win32/Glacid.A.

Compared to other attacks in the past, this attack is a little bit more complicated as different elements work together to achieve the whole attack. Each modularized component is designed to be configurable.

For example, when the original malicious SWF is downloaded from malicious server 1, the original malicious document is crafted to pass HTTP request parameters which will be used inside the malicious SWF file. The following packet capture shows one of the example requests we obtained. We can see that the request is using the “info” and “infosize” HTTP parameters. These parameters are later used in layer 2 SWF.

Figure 2 Malicious SWF Download Request

Here is the layer 2 SWF code which uses one of the dynamically passed parameters. The data dynamically passed is converted to binary form and is decompressed. The decompressed data is connection information about malicious server 2 which serves malicious data.

Figure 3 Parameter Usage Inside Layer2 SWF

As we saw from the overview diagram, layer 2 is loaded dynamically from the malicious SWF. The following code from the malicious SWF file shows how the layer 2 SWF file is loaded. The “loadBytes” method from “flash.display.Loader” class is called to load layer 2 SWF dynamically. This is a very typical way of loading malicious layer 2 SWF as seen in recent SWF malware.

Figure 4 Dynamic Loading Of Layer2 SWF Using loadBytes

One notable thing with the layer 2 SWF file is that it is using the”Shared Object” feature from Adobe Flash Player. This is the mechanism to save persistent data on a user’s machine which can be shared through sessions. When the same SWF file is loaded later, it can retrieve previously saved data from this “Shared Object”. By using this “Shared Object” feature, the malware avoids multiple exploitation attempts by checking the existence of the data and not performing the exploitation when it is found.

Figure 5 Usage Of Shared Object To Prevent Multiple Exploitation

As usually seen from malware abusing Adobe Flash Player, this malware is also using a heap spray technique to achieve shellcode execution. The following code part shows how the heap spray is happening. During this heap spray phase, you can observe that the application’s memory usage spikes.

Figure 6 Heap Spraying

The following picture shows what the shellcode sprayed on the memory looks like. When the exploitation is successful, the control flow is passed to one of these sprayed shellcodes in the memory.

Figure 7 Sprayed Shellcode On the Memory

The overall attack requires multiple modules to work together. We don’t see the attack as widespread yet. The vulnerability is not about the carrier that triggers the downloading of the SWF, but more of the Adobe Flash Player’s vulnerability. So, if you update your Adobe Flash Player, you can prevent the attack from affecting you.

Related detection name and SHA1 for the SWF exploits:

4d12200ede6cf44660399ca43c92fc87295b31cd detected as Exploit:SWF/CVE-2012-0779.A

53FE2CE5920CA0963638A68338433AD85F55BD0D detected as Exploit:SWF/CVE-2012-0779.B

c485712675509c233f70c64b84969b41164fab48 detected as Exploit:SWF/CVE-2012-0779.D

— Jeong Wook Oh & Chun Feng

Categories: Adobe, CVE-2012-0779, exploits Tags:

How to spot fraudulent tech support phone calls

May 24th, 2012 No comments

Betty writes:

I just received a call from a guy who said that my Windows was infected. He wanted me to sit in front of my computer while he fixed it. He became angry when I told him no and I hung up.

Thanks for writing, Betty. This type of call is a popular scam and you did exactly the right thing. Cybercriminals often use publicly available phone directories to call you and offer tech support. Once they’ve gained your trust, they might ask for your user name and password or ask you to go to a website to install software that will let them access your computer to fix it. If you do this, your computer and your personal information is vulnerable.

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

  • Never provide your credit card or financial information to someone claiming to be from Microsoft tech support.
  • Do not purchase any software or services.
  • Never give control of your computer to a third party unless you can confirm that it is a legitimate representative of a computer support team with whom you are already a customer.

Get more information on how to avoid tech support phone scams.

If you think you’ve been a victim of a tech support scam

If you think that you might have downloaded malware from a phone tech support scam website or allowed a cybercriminal to access your computer, take these steps:

  • Change your computer’s password. Change your Hotmail or other email password if you’ve given it to the caller.
  • Scan your computer with the Microsoft Safety Scanner to find out if you have malware installed on your computer. (This program automatically expires 10 days after you download it so it won’t clog your hard drive.)
  • Install Microsoft Security Essentials. (Microsoft Security Essentials is a free program. If someone calls you to install this product and then charges you for it, this phone call is also a scam.)

Quickly Identify, Classify and Protect your Data on Windows “8” Servers!

Announcing the Data Classification Toolkit for Windows Server “8” Beta!
A successful data classification program requires careful planning in these critical areas:

Identification of applicable IT GRC authority documents.

Documentation…(read more)

Quickly Identify, Classify and Protect your Data on Windows “8” Servers!

Announcing the Data Classification Toolkit for Windows Server “8” Beta!
A successful data classification program requires careful planning in these critical areas:

Identification of applicable IT GRC authority documents.

Documentation…(read more)

Quickly Identify, Classify and Protect your Data on Windows “8” Servers!

Announcing the Data Classification Toolkit for Windows Server “8” Beta!
A successful data classification program requires careful planning in these critical areas:

Identification of applicable IT GRC authority documents.

Documentation…(read more)

FBI warns against hotel net connections

May 22nd, 2012 No comments

The Federal Bureau of Investigation (FBI) issued a warning earlier this month that travelers should be careful using Internet connections in hotels. Some travelers had inadvertently downloaded malicious software onto their computers when they accepted fake security updates.

Reportedly, hackers had compromised hotel networks (mainly outside of the United States) so that when travelers tried to log on they would see a pop-up window indicating they needed to update their computer in order to get Internet access. The updates were actually malicious software designed to gain control of your computer and steal your personal information.

We recommend that you turn on automatic updating and visit Microsoft Update before you travel to help ensure that your computer is up to date. You can also increase your safety by connecting to the Internet in hotels through a cable instead of using a wireless connection.

Carl A. Someone has many names

May 22nd, 2012 No comments

In days of old, a man without a signature would just mark an ‘X’, but today it seems like there is another, more common, signature. I was doing some work the other day and came across a Word document that had an attachment. It turned out to be a phishing scam but part of the document caught my eye.

The signature did not match the name. The name was Dr. Simon Brown and the signature looks like this:

The signature was for Carl A. [indecipherable]. This made me wonder if it was just some generic image of a signature that scammers use. So after a search through our file collection and a stroll around the internet I found that I was correct – this is one very popular signature indeed with the phishing community. Now there are many blogs and sites out there that cover these scams in far more detail but this is what I found about files with this image embedded in it.

  • There have been scams using this signature in them since at least 2006.
  • The following are some of the names that have been attached to the signature in the phishing attachments:
    Dr. (Mrs.) Felicia Daniel Dr. (Mrs.) Mercy Hartemink Dr. Austin Benjamin
    Dr. Ferguson Andrew Dr. Frank West Dr. George Williams
    Dr. John Briggs Dr. Larry Smith Dr. Mack Anthony
    Dr. Mark Brown Dr. Mark Winters Dr. Martin Evans
    Dr. Matt Brown Dr. Richard Morrison Dr. Robert Mueller
    Dr. Smith Brown Dr. Smith Don Dr. Smith Williamson
    Dr. Steve Mark Dr. Tom Wilson Jenni Falconer
    Michelle Falkosky Mr. Christ Rawlins Mr. Daniel Rougerie
    Mr. Evans Henshaw Mr. Graham Smith Mr. James Norris
    Mr. Muhtar Kent Mr. Roberth Mueller Mr. Teddy Kennedy
    Mrs. Brunelli Naleen Mrs. Elizabeth Walters Mrs. Lisa Parker
    Mrs. Lourdes Vidaurre Mrs. Nicola Mckeon Mrs. Patricia.S.Brown
    Mrs. Rita Brown Mrs. Rosemary Clair Prof. Alex Kingston
    Prof. Martin Johnson R. Simon Brown Rev. James Moore
    Rev. Robert Morgan Sir. Muhtar Kent
  • At least 15 had the title of “Coca Cola Games/Lottery Coordinator”
  • The documents are all related to winning a prize of around £400,000 to £1,000,000 from different companies in England.
  • The following company names are among those that have been used illegitimately in these fake lotteries:
    BBC
    British High Commission
    British Telecom
    Coca-Cola
    ESPN
    Fifa World Cup
    Golf international
    Microsoft
    Nokia
    Toyota
    UK Lottery
    Yahoo

I suspect many of you have seen these emails, but if not they all follow the same sort of format. They tell you that you have won a prize and ask for a whole bunch of details so that you can claim that prize. I even came across one that wanted a photo. For those who have not seen them here are a few examples. Please note the signature on all of them, it should look familiar.

The oldest reference that I found to the signature on the web is a shipping company that dates their website to 2003. This leads me to believe that this was an open source image that the scammers have enjoyed using. (Unlike the various logos you see above, which are trade and service marks that are used illegally.)

I still do not know what the original name was though, Carl A…

– Michael Johnson
MMPC Melbourne

P.S. I do not think that I need to say it again but never open an email from someone that you do not know. It is very unlikely that you have won the Coca-Cola lottery or any lottery for that matter. Please use safe practices when dealing with email.

Categories: Uncategorized Tags:

MS12-034 – Critical : Combined Security Update for Microsoft Office, Windows, .NET Framework, and Silverlight (2681578) – Version: 1.2

Severity Rating: Critical
Revision Note: V1.2 (May 22, 2012): Added an entry to the Frequently Asked Questions (FAQ) Related to This Security Update section to explain this revision.
Summary: This security update resolves three publicly disclosed vulnerabilities and seven privately reported vulnerabilities in Microsoft Office, Microsoft Windows, the Microsoft .NET Framework, and Microsoft Silverlight. The most severe of these vulnerabilities could allow remote code execution if a user opens a specially crafted document or visits a malicious webpage that embeds TrueType font files. An attacker would have no way to force users to visit a malicious 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.

Categories: Uncategorized Tags:

Summary for May 2012 – Version: 2.1

Revision Note: V2.1 (May 22, 2012): For MS12-034, added footnotes for security update KB2660649 for Windows Server 2008 and Windows Server 2008 R2. There were no changes to the security update files. Customers who have successfully installed the update do not need to take any action.
Summary: This bulletin summary lists security bulletins released for May 2012.

Categories: Uncategorized Tags:

OSBC 2012: Advancing Interoperability in the Cloud

May 21st, 2012 No comments

At the Open Source Business Conference in San Francisco today, Sandy Gupta, the General Manager for Microsoft’s Open Solutions Group, along with Alan Clark, Director of New Initiatives and Emerging Standards for Open Source at SUSE, announced the release of a beta version of the SUSE Manager Management Pack for System Center.

In a blog post, Gupta said the announcement, which was made in collaboration with SUSE, lets this management pack connect the Linux server management capabilities provided by SUSE Manager to System Center, Microsoft’s management platform.

“As a result, customers will be able to administer both Windows and Linux environments from a single management console,” he said.

Gupta positioned the management pack as one example of the work Microsoft is doing to advance interoperability for private clouds. You can try the Linux management capabilities this management pack provides for System Center here.

“On the public cloud front, there’s extensive work going on across the company to facilitate interoperability between Microsoft and open source cloud tools and services. One of the most exciting examples of this comes from the SQL Server Team — the Hadoop-based service for Windows Azure, for which Microsoft released a second preview last month,” he said.

This solution for managing “big data,” connecting it and turning it into business insight, is a prime example of the type of value customers want to realize as a result of leveraging open source and Microsoft software together, he noted.

You can read his full blog post here.

Microsoft security updates and the Common Vulnerability Reporting Framework

May 17th, 2012 No comments

As a part of the Industry Consortium for Advancement of Security on the Internet (ICASI), Microsoft is pleased to present an initial set of monthly security updates – originally released on May 8 – in the consortium’s newly established Common Vulnerability Reporting Framework (CVRF) format, for your examination and feedback. Today, ICASI released version 1.1 of its CVRF – a markup system designed to make security bulletins and advisories machine readable in an industry-standard fashion.

Even though many vendors have followed Microsoft’s lead in providing comprehensive security updates to customers, the formats vendors use vary. CVRF provides the entire industry with a way to share and present data in a coordinated and structured manner.

CVRF is free for anyone to examine and use. The goal is to build a data-markup framework that can be used by anyone publishing or examining security update information on the Internet.

CVRF is a work in process. For many customers, a machine-readable markup framework for security releases might not be a pressing need. For instance, home-computer users or small businesses may choose to install security updates automatically. However, many business customers spend time “copying and pasting” our security bulletin content into their risk management systems, spreadsheets and corporate notification emails manually as part of their IT security compliance and remediation task list.

For these customers, this machine-readable format may enable more efficiency and automation. Faster and more efficient guidance for these customers means they can more quickly ensure protection, which is always our goal. For those that do not require automation, we will continue to offer our bulletins in the current format. For those customers looking to automate and streamline their security-management process, or for those who are simply curious to see what happens when vendors from around the industry roll up their sleeves and work to make the update process better, visit the Connect portal to read more about CVRF, and to examine CVRF-formatted bulletins. Visit https://connect.microsoft.com/ and click SIGN IN in the upper right-hand corner to sign in with your Windows Live ID. Once you are signed in and are looking at the home page, use the invitation code “cvrf-9BK8-6W2T” (without quotes) to join the program, or visit https://connect.microsoft.com/site1098/InvitationUse.aspx?ProgramID=7665&InvitationID=cvrf-9BK8-6W2T directly.

Your feedback will be relayed to the ICASI working group of which Microsoft is a member. Together we’ll continue to make CVRF a truly robust, collaborative standard throughout the Internet ecosystem.

Update: If you would like to find out more information about the CVRF standard, please join the CVRF working group webinar on Tuesday, 30 May at noon EDT. They will provide an overview of CVRF v1.1 and showcase the improvements in this latest revision. You can register at http://register.webcastgroup.com/L4/?wid=0557685978

Mike Reavey

Senior Director, MSRC

4 signs of scareware

May 17th, 2012 No comments

 “Scareware” is fake anti-virus software (also called “rogue security software”) that cybercriminals trick you into paying for or trick you into downloading along with malicious software. According to the latest Security Intelligence Report from Microsoft, one of the most prevalent forms of scareware is called Win32/FakePAV. Learn how to help prevent Win32/FakePAV from stealing your credit card information.

 Here are some tell-tale signs that could indicate a scareware infection:

  • Your computer runs  much slower than usual
  • When you try to surf the internet to legitimate anti-virus websites, you can’t get to them
  • You see a lot of pop-up windows with false or misleading alerts
  • The anti-virus software you recently downloaded is trying to lure you into upgrading to a paid version of the program

Get more information on how to spot fake virus alerts.

If you think you might have already download scareware, you can run the Microsoft Safety Scanner for free. Also, make sure you use legitimate anti-virus software, such as Microsoft Security Essentials, which is also free.

Microsoft was recently interviewed for a local Seattle news story about scareware. Watch the video

 

KB: DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010

imageHere’s a new Knowledge Base article we published. This one describes an issue where DirectAccess Manage Out fails for any non-ICMP traffic in UAG 2010.

=====

Symptoms

DirectAccess Manage Out does not work for any non-ICMP traffic in Microsoft Forefront Unified Access Gateway 2010. Outbound connections to external DirectAccess client machines fail for any traffic except for ICMP. If IPsec auditing is enabled you may see the following error when attempting to access the DirectAccess client:

4984 "An IPSec extended mode negotiation failed"

Cause

This issue can be caused by custom security policies regarding the local security rights for DirectAccess Manage-Out server and clients (e.g. modifying the setting "Access this computer from the network").

Manage-out connections require the ability of the source computer account and user account to authenticate IPsec connections to the remote DirectAccess client. Even though the IPsec tunnel is established from the DirectAccess server to client, the authentication occurs based on the internal source machine/account (impersonation).

The security policy for “Access this computer from network” controls the ability to authenticate and access system services on remote computers. This source machine/account must have this right granted for the remote resources for the DirectAccess Manage-Out capability to function. If the DirectAccess server machine account and the machine account of the internal source server used in impersonation do not have permissions to access the DirectAccess client machine from the network then IPsec authentication failures will occur.

Changes had been made to the local security policy which altered the default permissions for this access right. Everyone and Users groups were removed from the local security setting “Access this computer from network”.

Resolution

Reset the Local Security Setting for "Access this computer from the network" to the default configuration. By default this includes the following groups: Administrators, Backup Operators, Everyone, Users. The default setting is the only configuration which has been tested and verified for DirectAccess Manage Out connectivity.

More Information

2663354 – Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments : http://support.microsoft.com/default.aspx?scid=kb;EN-US;823659

=====

For the most current version of this article please see the following:

2704138 – DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Categories: Uncategorized Tags: