Posts Tagged ‘Microsoft Security Response Center’
Friday, April 26, 2013 @ 11:04 AM gHale
It is now safe. That is what Microsoft is saying about the re-released security update that caused users’ computers to crash and crippled the machines with countless supply of reboots.
The revamped MS13-036 update — first issued April 9, but pulled three days later from distribution — “resolves issues some customers experienced,” said Microsoft spokesman Dustin Childs.
“The new update, KB2840149, still addresses the Moderate security issue described in MS13-036, and should not cause these [rebooting] issues,” Childs added in a post to the Microsoft Security Response Center blog.
Two weeks ago, Microsoft yanked one of the two patches comprising MS13-036 from the Windows Update service as reports spread the fix was generating the notorious “Blue Screen of Death” (BSOD) error message and paralyzing PCs with repeated reboots.
Microsoft never clearly described the causes of the BSODs and endless reboots, saying at the time, “We’ve determined that the update, when paired with certain third-party software, can cause system errors.” Childs today also declined to get into specifics, instead saying only that “some customers were having issues.”
Customers and experts, however, pinned blame on combinations of the security update and “G-Buster,” a browser security plug-in widely used in Brazil for online banking; and on the Microsoft patch and Kaspersky Lab security software.
In a support document, Microsoft posted several error messages that were symptoms of the patch failure, and recommended that Windows 7 users uninstall the update.
The revised MS13-036 update is now in the Windows Update service, and will end up downloaded and installed by machines with Automatic Updates enabled. Microsoft urged those who manually download patches to deploy the re-release at their earliest convenience.
Tuesday, February 26, 2013 @ 02:02 PM gHale
Customers who lost access to Microsoft Azure cloud storage services last Friday need not file an outage report with Azure in order to be eligible for service credits, according to Microsoft.
The worldwide cloud outage was due to Microsoft’s failure to renew an SSL certificate, and that expired certificate resulted in customers being unable to connect to certain Azure Storage services that rely on use of SSL-encrypted transport to protect data.
So, under terms of the service-level agreement (SLA) for the Azure Storage services, customers must notify Azure customer support within five business days, which means Friday.
But because the problem was so widespread Microsoft is going to credit customers even if they don’t file a report.
“Given the scope of the outage, we will proactively provide credits to impacted customers in accordance with our SLA,” according to a Microsoft blog post written by Steven Martin, general manager of Windows Azure Business & Operations. “The credit will be reflected on a subsequent invoice.”
The SLA calls for a 10% credit for service uptime that falls below 99.9%. If uptime falls below 99%, the service credit jumps to 25% of Azure Storage charges for the month, according to the SLA Microsoft publishes for the service.
Microsoft says it is still trying to figure out what the underlying problem was that allowed the SSL certificate to expire and will post its findings on the Microsoft Security Response Center blog.
Microsoft says it noted the problem at 3:44 p.m. Eastern Friday and confirmed the service was fully restored at 11 p.m. Eastern Saturday.
Thursday, July 12, 2012 @ 01:07 PM gHale
In the wake of Flame, which used a fraudulent Microsoft digital certificate, the software giant found almost 30 that are not as secure so they revoked them.
Microsoft did not say where the now-untrusted certificates saw use, but company officials said there were 28 certificates affected by the move. Quite a few of the affected certificates list simply as “Microsoft Online Svcs.” However, the company said it was confident none of them suffered a compromise or ended up used maliciously. The move to revoke trust in these certificates is a direct result of the investigation into the Flame malware and how the attackers were able to forge a Microsoft certificate and then use it to impersonate a Windows Update server.
“As a continuation of this effort, we reviewed a number of Microsoft digital certificates and found several which do not meet our standards for security practices,” Gerardo Di Giacomo and Jonathan Ness of the Microsoft Security Response Center wrote in an explanation of the change. “As an extra precautionary measure, we released Security Advisory 2728973 today to announce the availability of a Critical, non-security update that moves several of these certificates into the Untrusted Certificate Store. None of the certificates involved are known to have been breached, compromised, or otherwise misused. This is a pre-emptive cleanup to ensure a high bar for any certificates owned by Microsoft.”
During the analysis of the Flame malware, researchers discovered one of the features of the worm was its use of a forged Microsoft certificate. The attackers used that certificate to set up a seemingly valid Windows Update server inside an infected organization and then have clients connect to the server, ostensibly for Microsoft updates, and then install the Flame malware on those machines.
That led to several changes in the way Microsoft handles certificates, and the revocation of trust in several of its own certificates is one of the more dramatic results. Several weeks ago the company said it would be releasing a mechanism for Windows that would automatically update the status of certificates in the certificate store. That was an optional update for Windows, but Microsoft changed that to a critical, non-security update, which means it will install automatically on most machines.
“This new feature provides dynamic updates, allowing Windows clients to be updated with untrusted certificates once per day without requiring user interaction,” Di Giacomo and Ness wrote.
Tuesday, June 5, 2012 @ 01:06 PM gHale
Analysis of the Flame code showed rogue Microsoft security certificates making it appear as if Microsoft officially signed it.
As a result, Microsoft issued a security advisory, revoked trust in the rogue certificates, and provided steps to help IT administrators and users prevent attacks.
“We have discovered through our analysis that some components of the malware have been signed by certificates that allow software to appear as if it was produced by Microsoft,” said a post on the Microsoft Security Response Center blog.
Flame slipped under network defenses by appearing as legitimate Microsoft code.
“The discovery of a bug that’s been used to circumvent Microsoft’s secure code certificate hierarchy is a major breach of trust, and it’s a big deal for every Microsoft user,” said Andrew Storms, director of security operations for nCircle. “It also underscores the delicate and problematic nature of the trust models behind every Internet transaction.”
The Microsoft blog post explains a vulnerability in an old cryptography algorithm is exploited by some elements of Flame to make them appear as if they originated from Microsoft. Most systems around the world accept officially-signed Microsoft code as safe by default, so the malware would enter unnoticed.
The weak algorithm is a function of the Terminal Server Licensing Service, which allowed IT administrators to authorize Remote Desktop services on Windows-based networks. The algorithm in question generated security certificates with the ability to sign code so it ends up accepted as legitimate Microsoft code.
Microsoft is taking steps to deal with this issue. First, it released the security advisory which explains the issue in detail and provides steps IT administrators can use to block software signed by the rogue security certificates. Microsoft also released an update, which automatically implements those same steps to make it easier for customers to prevent malware using the spoofed certificates from slipping through.
Microsoft added the Terminal Server Licensing Service is no longer capable of issuing certificates that can sign code. With these steps in place, organizations can rest assured any malware that depends on the rogue security certificates will no longer gain acceptance.
Tuesday, April 17, 2012 @ 05:04 PM gHale
A persistent script code inject vulnerability is hampering the Microsoft Partner Network Cloud service.
The hole ended up discovered by researchers from Vulnerability Lab who are helping Microsoft patch up some serious vulnerabilities that affected two of their services.
To demonstrate their findings, the researchers made a video proof-of-concept in which the Lab’s Chief Executive, Benjamin Kunz Mejri, shows how easy it is for an attacker to leverage the persistent script code injection flaws on a Microsoft Cloud aspx service to execute his own malicious code.
“The vulnerability allows a remote attacker or local low privileged user account to inject/implement malicious persistent script code (Application-Side). Successful exploitation with low required user inter action can result in session hijacking against admin, moderator and customer sessions or allows an attacker to manipulate requests via persistent script code inject,” the experts said.
After collaborating with the Microsoft Security Response Center (MSRC) team and after ensuring they addressed the issues, Vulnerability Lab made available the video and a proof-of-concept in text format that can offer some details.
The Microsoft Partner Network Cloud service wasn’t the only one found to have flaws. Microsofts Afkar, the site that allows Arabic users worldwide to play with new tools and ideas, contained a cross-site scripting (XSS) weakness that could have allowed a remote attacker to hijack user sessions and manipulate context.
In the past month, the Vulnerability Lab team has been very busy helping high-profile companies fix the bugs that exposed their websites and services to malicious operations.
First, they helped Microsoft address a flash component vulnerability that affected the Bing Service Application. Then, Shadab Siddiqui notified Apple on some dangerous SQL Injection vulnerabilities present in the Education Seminars & Events site.
Oracle’s security team also welcomed the feedback from the experts in handling multiple blind SQL Injection security holes that existed on sites such as campus.oracle.com, education.oracle.com, academy.oracle.com, and shop.oracle.com.
Tuesday, March 20, 2012 @ 01:03 PM gHale
The sample attack code created by Microsoft had likely leaked to hackers from a program it runs with antivirus vendors, officials said.
“Details of the proof-of-concept code appear to match the vulnerability information shared with Microsoft Active Protection Program (MAPP) partners,” said Yunsun Wee, a director with Microsoft’s Trustworthy Computing group.
“Microsoft is actively investigating the disclosure of these details and will take the necessary actions to protect customers and ensure that confidential information we share is protected pursuant to our contracts and program requirements,” Wee said.
Under MAPP, Microsoft provides select antivirus companies with technical information about bugs before Microsoft patches the flaws. MAPP gives third-party security vendors advance warning so they can craft detection signatures.
Among the things Microsoft shares with MAPP members are “proof-of-concept or repro tools that further illuminate the issue and help with additional protection enhancement.”
Microsoft’s revelation came after claims by Luigi Auriemma, the Italian researcher who reported the vulnerability in Windows Remote Desktop Protocol (RDP) in May 2011.
Auriemma said code found in a proof-of-concept exploit on a Chinese website was identical to what he had provided HP TippingPoint’s Zero Day Initiative (ZDI) bug bounty program. ZDI then used this code to create a working exploit as part of the bounty program’s bug verification work.
ZDI then passed along information about the RDP vulnerability, including the exploit that used Auriemma’s code, to Microsoft.
Auriemma said the public exploit included the string “MSRC11678,” a reference to a Microsoft Security Response Center (MSRC) case number, indicating the leak came from Microsoft.
ZDI denied it had been the source of the leak. “We’re 100% confident that the leak didn’t come from us, and Microsoft is comfortable with us saying that,” Aaron Portnoy, the leader of TippingPoint’s security research team and the head of ZDI.
Portnoy also described the chain of custody of Auriemma’s code — a specially-constructed data packet that triggers the RDP vulnerability — from its May 2011 submission to ZDI to its inclusion in the concept exploit that ZDI provided Microsoft in August 2011 as part of a broader analysis of the vulnerability.
The proof-of-concept exploit now circulating among hackers does not allow remote code execution — necessary to compromise a PC or server, and then plant malware on the system — but instead crashes a vulnerable machine, said Portnoy. The result: The classic Windows “Blue Screen of Death.”
Portnoy also echoed what Microsoft’s Wee said of the similarity between the public exploit and Auriemma’s code. “We can confirm that the executable [exploit] does have a packet that was part of what Luigi gave us,” Portnoy said.