SecurityFeed.info » Security Vulnerability Research & Defense

Security Vulnerability Research & Defense (10 unread)

March 02, 2010

Permalink for 'Security_Vulnerability_Research___Defense/2010/03/01/Help_keypress_vulnerability_in_VBScript_enabling_Remote_Code_Execution'

1:55

Help keypress vulnerability in VBScript enabling Remote Code Execution

» ‎ Security Vulnerability Research & Defense

The MSRC Engineering team has been investigating reports of a vulnerability involving the use of VBScript and Windows Help files.

What is the impact and affected platforms?

Our investigation has determined that Windows 7, Windows Server 2008, and Windows Vista are not impacted. Only Windows 2000 and Windows XP are impacted by default. Windows 2003 Server is also impacted, but the issue is mitigated in the default configuration due to the presence of the Internet Explorer Enhanced Security Configuration. With this issue, it is possible for a malicious web page to display a dialog box which will trigger the execution of arbitrary code when the user presses the F1 key. The prompt can appear repeatedly when dismissed, nagging the user to press the F1 key. Platforms are affected regardless of the Internet Explorer version installed.

How would a malicious user leverage this vulnerability?

Windows Help files are an inherently unsafe file format. That means these files can run arbitrary code, thus the browser must prevent remote Windows Help files from executing automatically.

VBScript functionality available from within Internet Explorer exposes the MsgBox function, allowing script on a web page to display a message to the user. The parameters supplied to the MsgBox function may reference an associated Window Help file, though this functionality is limited when VBScript is used within the browser. Though user interaction is required the F1 keyboard shortcut does enable an attack scenario. In the exploit, a file path enables a .HLP file to be loaded from the local filesystem, SMB, or WebDav.

Workarounds

As an interim workaround, users are advised to avoid pressing F1 on dialogs presented from web pages or other Internet content. If a dialog box appears repeatedly in an attempt to convince the user to press F1, users may log off the system or use Task Manager to kill the Internet Explorer process.

It is also possible to use the following command line to lock down the legacy Windows Help system, preventing it from loading:

cacls "%windir%winhlp32.exe" /E /P everyone:N

Command line to roll back this change:

cacls "%windir%winhlp32.exe" /E /R everyone

As this vulnerability is driven by scripting, the following standard workarounds apply as well:

Set Internet and Local intranet security zone settings to "High" to prompt before running ActiveX Controls and Active Scripting in these zones

You can help protect against exploitation of this vulnerability by changing your settings for the Internet security zone to prompt before running ActiveX controls and Active Scripting. You can do this by setting your browser security to High.

To raise the browsing security level in Internet Explorer, follow these steps:

1.	On the Internet Explorer Tools menu, click Internet Options.
2.	In the Internet Options dialog box, click the Security tab, and then click the Internet icon.
3.	Under Security level for this zone, move the slider to High. This sets the security level for all Web sites you visit to High.

Note If no slider is visible, click Default Level, and then move the slider to High.

Note Setting the level to High may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly even with the security setting set to High.

Impact of workaround. There are side effects to prompting before running ActiveX Controls and Active Scripting. Many Web sites that are on the Internet or on an intranet use ActiveX or Active Scripting to provide additional functionality. For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements. Prompting before running ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround. For each prompt, if you feel you trust the site that you are visiting, click Yes to run ActiveX Controls or Active Scripting. If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".

Add sites that you trust to the Internet Explorer Trusted sites zone

After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone. This will allow you to continue to use trusted Web sites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone.

To do this, follow these steps:

1.	In Internet Explorer, click Tools, click Internet Options, and then click the Security tab.
2.	In the Select a Web content zone to specify its current security settings box, click Trusted Sites, and then click Sites.
3.	If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box.
4.	In the Add this Web site to the zone box, type the URL of a site that you trust, and then click Add.
5.	Repeat these steps for each site that you want to add to the zone.
6.	Click OK two times to accept the changes and return to Internet Explorer.

Note Add any sites that you trust not to take malicious action on your system. Two in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com. These are the sites that will host the update, and it requires an ActiveX Control to install the update.

•

Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone

You can help protect against exploitation of this vulnerability by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone. To do this, follow these steps:

1.	In Internet Explorer, click Internet Options on the Tools menu.
2.	Click the Security tab.
3.	Click Internet, and then click Custom Level.
4.	Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK.
5.	Click Local intranet, and then click Custom Level.
6.	Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK.
7.	Click OK two times to return to Internet Explorer.

Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly.

Impact of workaround. There are side effects to prompting before running Active Scripting. Many Web sites that are on the Internet or on an intranet use Active Scripting to provide additional functionality. For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround. For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting. If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".

Add sites that you trust to the Internet Explorer Trusted sites zone

To do this, follow these steps:

1.	In Internet Explorer, click Tools, click Internet Options, and then click the Security tab.
2.	In the Select a Web content zone to specify its current security settings box, click Trusted Sites, and then click Sites.
3.	If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box.
4.	In the Add this Web site to the zone box, type the URL of a site that you trust, and then click Add.
5.	Repeat these steps for each site that you want to add to the zone.
6.	Click OK two times to accept the changes and return to Internet Explorer.

The Group Policy setting to “Turn off displaying the Internet Explorer Help Menu” under the Category Path “Computer ConfigurationAdministrative TemplateWindows ComponentsInternet Explorer” is not a sufficient mitigation for this issue.

Acknowledgements

Thanks to Robert Hensing for his work on the issue.

-David Ross, MSRC Engineering

February 24, 2010
21:05
Using code coverage to improve fuzzing results
» ‎ Security Vulnerability Research & Defense

Hi all,

I’m Lars Opstad, an engineering manager in the MSEC Science group supporting the SDL within Microsoft. I wanted to share with you some of the ways that we are improving our internal security practices, specifically in the area of file fuzzing.

Many fuzzers take a good file (template) as a starting point for creating malformed content. For years, dating back to Writing Secure Code in 2002, the SDL has encouraged people to fuzz their file parsers with a “good representative set” of template files. The question is “how do I tell if I have a good set?” At Microsoft, our answer is code coverage, which is in line with other external research (Guruswami, Miller, and Sutton, Greene and Amini to cite only a few).

Code Coverage Definition

Before getting into how we use code coverage for fuzzing, I should briefly define the terms. If you are well versed in these concepts, feel free to skip to “Using Coverage for Better Fuzzing.”

Code coverage is a measure of how well a set of code is exercised based on a set of tests or inputs. The simplest scheme of code coverage is at the function level. Functional coverage measures which functions were called and which functions were not called. While this is useful at a very broad level, it does not really provide the granularity necessary to measure meaningful coverage for a file parser. A better metric is “block” coverage. A basic block in coverage terms is a section of code that always executes in sequence with no jumps in or out. Take the following code sample:

x+=1;                                     // block 1
y+=2;
if(

sin(x)

                <                              // block 2 (although executes after block 3)

                sin(y)    )              // block 3

{                                              // block 4
                y+=1;
                result=true;
}

else                                       // block 5
{
                result=false;
}

x+=1;                                     // block 6
return result;

For the above example, there are two main coverage cases depending on whether sin(x)<sin(y) or not. If it is, the blocks covered will be (in order of execution) 1, 3, 2, 4, 6 (not 5). If not, the blocks covered will be 1, 3, 2, 5, 6 (not 4). For full coverage, both those cases are necessary.

There are additional coverage concepts that can be useful in more detailed analysis, but for the purpose of this post, that lays a good foundation.

There are many free and commercially available coverage tools (including one built into Visual Studio, described here) that will give you this type of information. The focus of this post is not on any one tool, but using the measurements to improve file fuzzing effectiveness.

Using Coverage for Better Fuzzing

Our first goal with using coverage for fuzzing was simply to evaluate the overall completeness of a template set. This was achieved by measuring each template running through the application and calculating the overall block coverage of the parser code. The most important part of this exercise was performing the gap analysis when coverage was too low (e.g. less than 60%). Through the gap analysis, the team could then find or build additional templates that exercised the remaining code. For example, with a standard RIFF format, it is possible that one type of tag was missing from all the templates. With that knowledge, the owner of that component could easily find or generate a file that contains the missing record type and increase the coverage appropriately.

After doing some work in this area, we realized that many template files covered almost exactly the same blocks of code. Fuzzing one of these templates is roughly equivalent with fuzzing any of the other similar templates. We wanted to be able to increase our odds of hitting the less frequently used parts of code, under the basic assumption that bugs are much more common in the less tested parts of the code. Thus, we wanted to reduce duplication and choose the fewest number of templates while still providing equivalent coverage relative to our full original set.

Technical Details of Coverage Based Template Optimization

The algorithm we used to choose the optimized set of templates is known as the Greedy Algorithm, and operates under the premise of choosing the best fit, then the next best fit and so on. In this particular case, here is the pseudo-code for our algorithm (after having gathered coverage for each template):

while (FullTemplateList.count>0)

{

Template candidate=null;

foreach (Template t in FullTemplateList)

{

                                if (candidate==null || t.BlocksCovered>candidate.BlocksCovered)

                                {

                                                candidate=t;

                                }

}

FullTemplateList.Remove(candidate);

OptimalTemplateList.Add(candidate);

// Exclude blocks from candidate template from coverage of other templates

foreach (Template t in FullTemplateList)

{

                t.CoverageMask = t.CoverageMask & ~candidate.CoverageMask;

                t.BlocksCovered=t.CoverageMask.BlocksSet();

                if (t.BlocksCovered == 0)

                {

                                FullTemplateList.Remove(t);

                }

}

}

To illustrate this algorithm, assume you have measured the coverage of seven input files that have given you the following masks:

FullTemplateList:

Template A

Template B

Template C

Template D

Template E

Template F

Template G

The best choice from this list is Template B, with six blocks covered. After one iteration of the loop, the lists would look like (gray blocks indicating blocks covered by the original template that already have coverage in the OptimalTemplateList):

OptimalTemplateList:

Template B

FullTemplateList (remaining):

Template A

Template C

Template D

Template F

Removed:

Template E

Template G

Ultimately, this would result in four templates in the OptimalTemplateList:

Template B

Template C

Template A

Template D

Results from Template Optimization

Coverage-based template optimization was first used at Microsoft during the development of Windows Vista. Applying the algorithm above yielded a significant reduction in the number of templates necessary to cover the file parser. In examining 90,000 JPG files parsed by MSHTML.DLL (used in Internet Explorer), we identified <100 files that gave the same coverage as all 90,000. Due to this, finding issues near blocks of code covered only by one template increased in odds by a factor of 900.

While investigating one MSRC case, Gavin Thomas from MSRC Engineering used template optimization to see how effective a small, optimized set of templates were in comparison to a normal, large set of templates. For this test, he used two different mutation fuzzers and ran them for 500,000 iterations each. The issue count was nearly twice for the optimized set for either fuzzer:

Conclusion

Code coverage is only one approach to improving the fuzzing process. While it does not guarantee that you will find all of the bugs in your product, it increases the probability that your fuzzer will reach the less frequently exercised parts of your code because you reduce the time spent exercising more common blocks of code. MSEC encourages software development teams to use this technique to maximize the efficacy of their fuzz testing.

Thanks to Adel Abouchaev and Michael Levin for refinements in the algorithm, Gavin Thomas and Andy Renk for experiments verifying effectiveness, Michael Howard for historical perspective, and Damian Hasse and Matt Miller for technical review.

Thanks,

Lars Opstad, MSEC Science
February 09, 2010

Permalink for 'Security_Vulnerability_Research___Defense/2010/02/09/Assessing_the_risk_of_the_February_Security_Bulletins'

20:05

Assessing the risk of the February Security Bulletins

» ‎ Security Vulnerability Research & Defense

This morning, we released 13 security bulletins. Five have maximum severity rating of Critical, seven Important, and one Moderate. One security bulletin (MS10-015, ntvdm.dll) has exploit code already published, but we are not aware of any active attacks or customer impact. We hope that the table and commentary below helps you prioritize the deployment of the updates appropriately.

Bulletin	Most likely attack vector	Max Bulletin Severity	Max Exploit- ability Index	Likely first 30 days impact	Platform mitigations
MS10-013 (Quartz)	Victim opens malicious AVI or WAV file.	Critical	1	Likely to see working exploit in next 30 days.
MS10-007 (ShellExecute)	Attacker hosts a malicious webpage, lures victim to it.	Critical	1	Likely to see exploit code released resulting in binary on WebDAV share being executed. For more detail, see this SRD blog post.
MS10-006 (SMB Client)	Locally logged-in attacker with low privilege runs a malicious executable to elevate to high privilege.	Critical	1	Likely to see working exploit code for local attacker escalation. For more detail, see this SRD blog post.
MS10-008 (ActiveX kill-bits)	Attackers host a malicious webpage, lures victim to it	Critical	n/a third party code not rated for exploitability	Likely to see working exploit for vulnerabilities in third party ActiveX controls.
MS10-012 (SMB Server)	Attacker sends network-based malicious connection to remote Windows machine via SMB.	Important	1	Likely to see working proof-of-concept in next 30 days for CVE-2010-0231 resulting in attacker luring remote victim user to open file on attacker server and initiating a connection back to machine where remote victim is logged on. Less likely to see working exploit code for the authenticated code execution vulnerability (CVE-2010-0020) or unauthenticated denial-of-service vulnerabilities (CVE-2010-0021 and 0022) For more detail, see this SRD blog post.
MS10-015 (Kernel)	Attacker already able to execute code as low-privileged user escalates privileges.	Important	1	Proof of concept code already widely available. No active attacks.
MS10-011 (CSRSS)	Attacker who logs onto console of system where victim later logs onto console of same system can potentially run code with victim’s identity.	Important	1	Likely to see proof-of-concept code published for this vulnerability. However, unlikely to see wide-spread exploitation due to extensive user interaction required.
MS10-009 (TCP/IP)	Attacker sends network-based attack against system on local subnet.	Critical	2	May see denial-of-service proof-of-concept code published leveraging CVE-2010-0239 or CVE-2010-0241. Attackers are less likely to discover real-world attack surface in next 30 days for CVE-2010-0240.	/GS effective mitigation for CVE’s: CVE-2010-0239 CVE-2010-0240 CVE-2010-0241. CVE-2010-0242 is denial of service only.
MS10-003 (Excel)	Attack sends malicious .xls file to victim who opens it with Office XP or lower. (Office 2003, 2007 not affected.)	Important	1	Likely to see working exploit file effective on Office XP in first 30 days.	Office 2003 and Office 2007 not affected.
MS10-004 (PowerPoint)	Attacks malicious .ppt file to victim who opens it with Powerpoint Viewer 2003.	Important	1	Likely to see working exploit file effective on PowerPoint Viewer 2003. However, PowerPoint Viewer 2003 was replaced online by PowerPoint Viewer 2007. Only victims who use PowerPoint Viewer 2003 from Office 2003 install disk would be vulnerable to the PowerPoint Viewer vulnerabilities. Less likely to see working exploit for other PowerPoint vulnerabilities.	PowerPoint Viewer cases not exploitable for code execution on Windows XP or Windows 2000.
MS10-010 (Hyper-V)	Attacker running code on virtual machine crashes host OS.	Important	3	Unlikely to see working exploit code in next 30 days.
MS10-014 (Kerberos)	Attacker potentially able to cause denial of service via Kerberos traffic if victim server configured with trust relationship to MIT Kerberos realm.	Important	3	Unlikely to see public exploit code in next 30 days.
MS10-005 (GDI+)	Attacker sends malicious JPEG to victim. Victim saves JPG, launches mspaint, and then file->opens the malicious JPEG	Moderate	1	Likely to see exploit code developed. Unlikely to have broad impact as mspaint is not registered file association for JPEG.

We also released Security Advisory 977377 covering the TLS man-in-the-middle vulnerabilities disclosed several months ago. The advisory describes more about the Microsoft attack surface (and a mitigation option). You can read our blog post about the issue here: [blogs.technet.com].

Thanks to all of MSRC Engineering for providing data for this table. Thanks Jerry Bryant, Andrew Roths, and Mark Wodrich for your ordering / priority thoughts.

- - Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Update Feb 10 - Changed Exploitability Index rating for third party killbits to "n/a" as we do not rate exploitability of third party vulnerabilities.

Update Feb 25 - Thanks to Secunia for sending in the PowerPoint Viewer question. Listed non-exploitable platforms in the table above.

20:01
MS10-007: Additional information and recommendations for developers
» ‎ Security Vulnerability Research & Defense
Today we are releasing MS10-007 to address a URL validation issue generally applicable to the ShellExecute API.

How would a malicious user leverage this vulnerability?

This issue involves how ShellExecute handles strings that appear to be legitimate URLs, but are malformed such that they result in execution of arbitrary code. Various technologies use ShellExecute to initiate a browser navigation. It is assumed that the operation is safe if the parameter passed to ShellExecute “looks like a URL.” It seems reasonable to expect that if a string is a valid URL, it cannot possibly result in execution of arbitrary code when processed by ShellExecute.

But while it may be valid to assume that
```
ShellExecute(URL)
```
will not execute a system command, it should be understood that the core purpose of the ShellExecute API is to execute files. This vulnerability involves the use of a valid-looking URL that ShellExecute will run as a system command. To get exploited, a user might click on a link appearing outside the context of the browser, for example as an address book contact. At that point, a remote executable could run without prompting.
Recommendations for Developers

We recommend that application developers wishing to use ShellExecute for URL-based navigation take a conservative approach to validation. First, developers should heed the specific guidance in KB943552 as it pertains to this scenario. Additionally, rather than simply validating that a URL is of the format [scheme]://[FQDN]/[path]?[querystring], it is advisable to also validate that the URL scheme is one of a specific set of allow-listed URL schemes, for example “http” or “https.” This is consistent with guidance provided in Chapter 4 of the Microsoft Design Guidelines for Secure Web Applications.

As it turns out, many commonly-used code paths actually do perform this level of URL scheme validation and thus do not present viable attack vectors, even in the presence of the ShellExecute bug. Defense-in-depth FTW!

Acknowledgements
Thanks to Chengyun Chu for insight and analysis on this issue.

- David Ross, MSRC Engineering
*Posting is provided "AS IS" with no warranties, and confers no rights.*
20:00
MS10-006 and MS10-012: SMB security bulletins
» ‎ Security Vulnerability Research & Defense
Today we released two bulletins to address vulnerabilities in SMB. MS10-006 addresses two vulnerabilities in the SMBv1 client implementation, and MS10-012 addresses four vulnerabilities in the SMB server implementation. In this blog entry, we want to help you understand the vulnerabilities and better prioritize the updates.

What are the SMB server vulnerabilities and how could they be exploited?

The first issue is an authenticated remote code execution (RCE) vulnerability (CVE-2010-0020) in the server SMBv1 implementation on all versions of Windows. A long filename can lead to kernel pool memory corruption in an error path. This issue has a severity rating of important as an attacker needs to be authenticated to perform the attack.

The second and third issues (CVE-2010-0021 and CVE-2010-0022) are remote unauthenticated denial-of-service (DoS) vulnerabilities in the SMBv1 and SMBv2 server implementations and have Important severity ratings. CVE-2010-0021 is caused by a race condition when handling valid Negotiate requests. CVE-2010-0022 is caused by an integer underflow when handling a path name in the SMB request.

The final server-side issue is CVE-2010-0231, an Important-severity remote unauthenticated elevation of privilege (EoP) affecting all versions of Windows. This issue is unusual in that it is caused by weak entropy in the cryptographic challenge values generated by SMB. An attacker could exploit this issue and gain access to the SMB server under the credentials of an authorized user.

We recommend placing higher priority on the SMB server-side update due to the risk of RCE and EoP on all systems.

What are the SMB client vulnerabilities?

The first issue is a Critical severity kernel pool memory corruption vulnerability (CVE-2010-0016) in the client SMBv1 implementation on Windows 2003 and below. The vulnerability happens during the SMB client/server negotiation phase and does not require authentication. A remote attacker who successfully exploits this issue could gain complete control of the target system.

The second one is an Important severity race condition in the client SMBv1 code on Windows Vista and higher (CVE-2010-0017). The vulnerability is in the SMB client/server negotiation phase and does not require authentication. The severity of this issue depends on the version of Windows on the client computer:
- On Windows Vista and Windows Server 2008 a remote attacker would not be able to gain control of a target system using this vulnerability; instead the impact would be a system DoS. However, a local authenticated user could potentially exploit this vulnerability and gain control of the system. On these platforms, the severity of this issue is Important. The update should be prioritized for Terminal Servers and other system that allow users to log on locally.
- On Windows 7 and Windows Server 2008 R2 a remote attacker can potentially gain control of a target system using a variation of this vulnerability. Due to the RCE impact, the severity of this issue on these platforms is Critical. Unsuccessful attempts to exploit the vulnerability would result in a system DoS. This update should be applied to all affected systems due to the RCE risk; however, due to the nature of the issue, DoS is much more likely.
Why does the SMB client update have an aggregate severity of Critical on Windows 7 and Windows Server 2008 R@, but only Important on Vista and Windows Server 2008?

As outlined above, CVE-2010-0017 affects Vista and higher systems and is rated Important on Vista and Windows Server 2008. However, on Windows 7 and Windows Server 2008 R2, the severity is higher (Critical) due to the risk of RCE. The reason for this difference is a design change made during the Windows 7 development process, when the SMB client code moved to use a new kernel-mode networking I/O mechanism – Winsock Kernel (WSK). This change exposed the SMB client code to different timing conditions, exposing a race condition. This race condition is different to the issue present on Vista and Windows Server 2008, although it is reachable under similar conditions.

It should be noted that WSK is not the source of the vulnerability and no change to WSK is being made in this update.

How could a malicious user exploit the SMB client vulnerabilities?

It is important to understand that both of the vulnerabilities in MS10-006 are in the SMB client implementation and do not affect SMB server roles. (For more details regarding SMB client/server roles, see ref. 2 below) Therefore, in order to exploit this vulnerability, an attacker would have to setup a malicious SMB server and trick the client to connect to it. If your environment does not allow outbound SMB connections to the Internet (best practice), then you are protected from the Internet attack vector. A malicious user on the local network (or a compromised computer) would be able to exploit this issue by performing man-in-the-middle attacks and responding to SMB requests from clients within the Intranet.

The Internet attack vector would involve browsing to a malicious or compromised website, or receiving HTML email with embedded links to a malicious SMB server. If a victim attempted to retrieve the files or other content specified in the HTML file, an outbound SMB connection would be made and assuming SMB traffic were allowed through the perimeter firewall, the issues could be exploited.

Depending on your environment, you may not need to place a high priority on the SMB client-side update.

We would like to thank Dustin Childs from MSRC and Kowshik Jaganathan and the Windows Sustained Engineering team for their hard work on this update.

- Bruce Dang and Mark Wodrich, MSRC Engineering

References:

1. Winsock Kernel on MSDN ([blogs.msdn.com])
2. SMB client/server roles (http://msdn.microsoft.com/en-us/library/aa365233(VS.85).aspx)
19:00
Details on the New TLS Advisory
» ‎ Security Vulnerability Research & Defense

Security Advisory 977377: Vulnerability in TLS Could Allow Spoofing

In August of 2009, researchers at PhoneFactor discovered a vulnerability in the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. As the issue is present in the actual TLS/SSL-standard, not only our implementation, Microsoft is working together with ICASI, the Industry Consortium for Advancement of Security on the Internet to address this vulnerability. Today, Microsoft released an advisory and an associated workaround package that experienced administrators can use to protect their web services.

Explaining the risk of the security vulnerability

The issue, CVE-2009-3555, allows an attacker who successfully became a man-in-the-middle to prepend information to a TLS/SSL protected connection. It does not allow an attacker to read, change or edit the encrypted data. This vulnerability exists because certain SSL-protected protocols, such as HTTP, assume that information received after a TLS-renegotiation is sent by the same client as the information sent before that renegotiation. Renegotiation is a feature of the TLS protocol, described in RFC 2246 which allows either peer to renegotiate the parameters of a protected connection at any point in time. An attacker could exploit this vulnerability by intercepting a legitimate connection from a client, then initiating a renegotiation to the vulnerable server, or by piggybacking on a TLS renegotiation initiated by the web server.

This vulnerability can affect different protocols that use TLS/SSL, but most clearly affected is the HTTPS protocol which protects web transactions.

IIS 6, IIS 7, IIS 7.5 not affected in default configuration

Customers using Internet Information Services (IIS) 6, 7 or 7.5 are not affected in their default configuration. These versions of IIS do not support client-initiated renegotiation, and will also not perform a server-initiated renegotiation. If there is no renegotiation, the vulnerability does not exist. The only situation in which these versions of the IIS web server are affected is when the server is configured for certificate-based mutual authentication, which is not a common setting.

Scope of the vulnerability in IIS 5

IIS 5 does allow clients to initiate a TLS renegotiation and is vulnerable in its default configuration. Our investigation has shown it is unlikely that these attacks will be exploited successfully. An attacker would already need to successfully leverage a man-in-the-middle attack to intercept a connection between a client and vulnerable server in order to exploit this vulnerability.

Likelihood of the vulnerability being exploited in general case

Eric Lawrence, a Program Manager in the Internet Explorer security team also evaluated the exploitability of the vulnerability and found the following:

The below is an example of an exploitation of this vulnerability. The text in red is prepended to an SSL connection by an attacker, the text in blue is sent by the unwitting victim client, and the text in green is the web server’s response:

GET /app/transaction.asp?action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000 HTTP/1.1
X-Ignore-This-Line: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)

Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk

Host: www.victim.com

HTTP/1.1 200 OK
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close

<html><body>Successfully sent $2000USD from account #12345 to account #6666.</body></html>

The lines highlighted in yellow represent client state or identification information; by being in the same header block as the attacker’s request, they effectively authorize that spliced request.

There are two reasons why this attack is unlikely to be exploited:

· If a site is vulnerable to this attack, they are almost certainly vulnerable to classic Cross Site Request Forgery style of attack. The attacker need only send the client some HTML containing an IMG SRC to the victim URL and the client will dereference that URL, automatically providing the credentials to the server. This is a simpler mechanism of accomplishing the same thing than the more complicated TLS/SSL and request-splicing attack hopes to achieve.

· If an attacker were able to overcome the previous issue, this technique will not work for a site that only accepts parameters via HTTP POST requests. The reason is that the attacker must convey the malicious request within the POST’s body. By definition, the HTTP POST body occurs after the request header block has completed. So, the malicious attack would look something like this:

POST /app/transaction.asp HTTP/1.1
Host: www.victim.com

Content-Type: application/x-www-form-urlencoded

Content-Length: 62

action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)

Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk

Host: www.victim.com

HTTP/1.1 400 Bad Request
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close

<html><body>Credentials required.</body></html>

Because the victim’s spliced request is sent after the header block, the credentials will not be used to authenticate the submitted transaction. The only way an attacker could make this work is if the server accepted what are called “Trailer” headers from the HTTP request, like so:

POST /app/transaction.asp HTTP/1.1
Host: www.victim.com

Content-Type: application/x-www-form-urlencoded

Transfer-Encoding: chunked

Trailer: Authorization, Cookie, X-Ignore

3E
action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000
0
X-Ignore: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)

Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk

Host: www.victim.com

However, it is unlikely that real-life web applications actually would accept this type of Trailer header, as it is a very little-used part of HTTP, not supported by mainstream browsers such as Internet Explorer.

Workaround package available to disable TLS renegotiation

While a comprehensive, multi-vendor fix is in the works, today we released a workaround package which allows system administrators to disable TLS renegotiation on their server. This package is described in KB article 977377 and disables TLS/SSL renegotiation for all TLS/SSL-protected protocols. We need to stress that TLS/SSL renegotiation is a feature of the protocol that is used by several applications. One common example is Microsoft Exchange and ActiveSync. These applications may operate inappropriately upon installation of this workaround package. We recommend that administrators carefully test the workaround prior to deploying it on production systems. The package will protect all clients making SSL connections to the server on which it is installed. Installing it on clients will not provide any security benefit.

We recommend that customers only install this workaround if they have very specific concerns regarding this vulnerability and require an ad-interim solution while Microsoft and other vendors work on a revision of the protocol.

Despite the low risk of active exploitation, this vulnerability breaches a security promise made by the TLS protocol and we intend to address it comprehensively. We are working with the relevant standards body and our partners in ICASI to ensure that our fix for this issue is compatible with third party SSL/TLS-enabled solutions.

Thanks to Nasko Oskov from Windows Security, Eric Lawrence from Internet Explorer and Jonathan Ness from the MSRC Engineering team for their significant contributions to this blog post.

-Maarten Van Horenbeeck, MSRC Program Manager
*Posting is provided "AS IS" with no warranties, and confers no rights.*
January 20, 2010

Permalink for 'Security_Vulnerability_Research___Defense/2010/01/20/Reports_of_DEP_being_bypassed'

20:01

Reports of DEP being bypassed

» ‎ Security Vulnerability Research & Defense

Yesterday we heard reports of a commercially available exploit that bypasses DEP. This exploit was made available to a limited number of major security vendors (Antivirus, IDS, and IPS vendors) and government CERT agencies. We wanted to use this opportunity to give an overview of current customer risk related to this DEP bypass.

Real-world attacks so far still only effective against Internet Explorer 6

We have seen an increase in attacks attempting to exploit the vulnerability detailed in Security Advisory 979352. However, all attacks we have seen so far still target Internet Explorer 6 - this is also confirmed by the attack samples our Microsoft Active Protections Program (MAPP) partners have sent in.

While we have not seen real-world attacks for any other platform, we have seen researchers poking at other platforms and have seen the following:

Private proof-of-concept code exploiting IE7 on Windows XP for arbitrary code execution
Private proof-of-concept code exploiting IE7 on Windows Vista without DEP enabled for code execution within the Protected Mode sandbox. We are not aware of any proof-of-concept code exploiting Windows Vista with DEP enabled.
Commercial, limited distribution proof-of-concept code exploiting IE8 on Windows XP with DEP enabled for arbitrary code execution.

State-of-the-art of attacker research on various platforms

Here’s the current state-of-the-art on each platform:

	Windows XP	Windows Vista	Windows 7
IE 6	Public exploit code consistently reliable for arbitrary code execution	N/A	N/A
IE 7	Private proof-of-concept is likely consistently reliable for arbitrary code execution	Private proof-of-concept is likely consistently reliable for limited code execution within the Protected Mode sandbox.	N/A
IE 8	In our testing, the commercially-available, limited distribution exploit does result in successful code execution with DEP enabled.	No known proof-of-concept code. Current exploits modified for use on Windows Vista would likely be effective for limited code execution within the Protected Mode sandbox on 1% of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows Vista.	No known proof-of-concept code. Current exploits modified for use on Windows 7 would likely be effectively for limited code execution within the Protected Mode sandbox on 1% of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows 7.

Other mitigations (besides DEP)

We have discussed DEP at length in this blog. As you can see in the table above, two other mitigations help prevent or limit the impact of attacks on later platforms.

Internet Explorer Protected Mode limits the impact of Windows Vista and Windows 7 exploits. Attackers who are able to successfully exploit Internet Explorer on those platforms are stuck in a “sandbox”, potentially able to read data but unable to install programs or change system configuration.
Address Space Layout Randomization (ASLR) makes exploiting vulnerabilities more difficult by relocating normally-predictable code locations pseudo-randomly in memory. ASLR re-bases DLL’s to random locations in memory, making ret2libc type attacks unreliable. Due to ASLR we believe exploits for Internet Explorer 8 on Windows Vista or Windows 7 could result in limited code execution for 1% of attempts.

Out-of-band update coming tomorrow

We’ll be releasing a comprehensive, well-tested security update tomorrow morning PST to address this vulnerability. In the meantime, we hope this information helps you assess risk and protect your environment.

Acknowledgements

Thanks Matt Miller and John Lambert for help with the ASLR arithmetic and other feedback.

Update Jan 20, 2010: Updated "less than 1%" to "1%". Thanks reader Larry for catching arithmetic error.

Update Jan 22, 2010: Updated to reflect new understanding of the commercially-available, limited distribution exploit on IE8 / XP SP3. Also removed formula behind the theoretical 1% ASLR success chance. The formula was off by a fraction of a percentage point and the math to describe it would be difficult to explain. The chance is approximately 1.1%.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

January 19, 2010

Permalink for 'Security_Vulnerability_Research___Defense/2010/01/18/Additional_information_about_DEP_and_the_Internet_Explorer_0day_vulnerability'

4:13

Additional information about DEP and the Internet Explorer 0day vulnerability

» ‎ Security Vulnerability Research & Defense

The new Internet Explorer security vulnerability described by Microsoft Security Advisory 979352 has received a lot of interest over the past few days. The Internet Explorer team is hard at work preparing a comprehensive security update to address the vulnerability and the MSRC announced today that as soon as the update is ready for broad distribution, it will be released.

We have heard several questions from customers attempting to protect their environment in the meantime. Most questions have been around Data Execution Prevention (DEP), a mitigation we discussed in our previous blog post. To help you better understand DEP specifically as it relates to Internet Explorer 8, we have prepared the following video where I discuss some of the higher level concepts:

More listening and viewing options:

To summarize:

Which versions of Internet Explorer have enabled DEP by default?

Hardware-enforced DEP is enabled by default for Internet Explorer on the following platforms:

· Internet Explorer 8 on Windows XP Service Pack 3,

· Internet Explorer 8 on Windows Vista Service Pack 1 and later,

· Internet Explorer 8 on Windows Server 2008, and

· Internet Explorer 8 on Windows 7.

Windows 2000 has no support for hardware-enforced DEP. Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and Windows Vista support hardware-enforced DEP do not have the SetProcessDEPPolicy API that Internet Explorer 8 uses to enable DEP.

How can users of other versions of Windows or Internet Explorer enable DEP?

Windows XP SP2 and Windows Vista RTM users can click this button to launch an MSI that will enable DEP for Internet Explorer.

How can you determine whether hardware-enforced DEP is available with your hardware?

Microsoft KB 912923 describes in more detail how to determine that hardware DEP is available and configured on your computer.

What is the difference between "Software DEP" and hardware-enforced DEP (/NX)?

"Software DEP" is unfortunately really not DEP at all. "Software DEP" is just another name for /SAFESEH [MSDN link]. Unfortunately, /SAFESEH is not an effective mitigation for this vulnerability. Only hardware-enforced DEP disrupts exploits attempting to abuse this vulnerability.

Does IE’s DEP behave differently in the Intranet Zone (as compared to the Internet Zone)?

DEP itself is enabled per process, regardless of application-layer content. However, a well-known DEP bypass is used by attackers to mark pages executable using .NET classes. IE8 does not allow these .NET class to load in the Internet Zone. In the Intranet Zone, the .NET classes are allowed to load. Therefore, an attacker capable of hosting content on your corporate network may be able to bypass DEP and successfully exploit this vulnerability.

We hope that helps answer questions you may have had about DEP.

Jonathan Ness

*This posting is provided "AS IS" with no warranties, and confers no rights*

January 16, 2010

Permalink for 'Security_Vulnerability_Research___Defense/2010/01/15/Assessing_risk_of_IE_0day_vulnerability'

2:00

Assessing risk of IE 0day vulnerability

» ‎ Security Vulnerability Research & Defense

Yesterday, the MSRC released Microsoft Security Advisory 979352 alerting customers to limited, sophisticated attacks targeting Internet Explorer 6 customers. Today, samples of that exploit were made publicly available.

Before we get into the details I want to make one thing perfectly clear. The attacks we have seen to date, including the exploit released publicly, only affect customers using Internet Explorer 6. As discussed in the security advisory, while newer versions of Internet Explorer are affected by this vulnerability, mitigations exist that make exploitation much more difficult. We would like to share a little more information about both the vulnerability and the exploits we have seen to help you understand the risk to your organization.

Risk, by platform

Newer versions of Internet Explorer and later Windows releases are at reduced risk to the exploit we have seen due to platform mitigations explained in the blog post below. (Note: Server platforms are omitted from this table because browsing is less likely from Servers.)

	Windows 2000	Windows XP	Windows Vista	Windows 7
Internet Explorer 6	Exploitable	Exploitable (current exploit effective for code execution)	N/A (Vista ships with IE7)	N/A (Windows 7 ships with IE 8)
Internet Explorer 7	N/A (IE 7 will not install on Windows 2000)	Potentially exploitable (current exploit does not currently work due to memory layout differences in IE 7)	IE Protected Mode prevents current exploit from working.	N/A (Windows 7 ships with IE 8)
Internet Explorer 8	N/A (IE 8 will not install on Windows 2000)	DEP enabled by default on XP SP3 prevents exploit from working.	IE Protected Mode + DEP enabled by default prevent exploit from working.	IE Protected Mode + DEP enabled by default prevent exploit from working.

As you can see, the client configuration currently at risk is Windows XP running IE6. We recommend users of IE6 on Windows XP upgrade to a new version of Internet Explorer and/or enable DEP. Users of other platforms are at reduced risk. We also recommend users of Windows XP upgrade to newer versions of Windows.

More information about the vulnerability

The vulnerability is an Internet Explorer memory corruption issue triggered by an attacker using JavaScript to copy, release, and then later reference a specific Document Object Model (DOM) element. If an attacker is able to prepare memory with attack code, the reference to a random location of freed memory could result in execution of the attacker’s code.

Ways to block Code Execution

The vulnerability is present in Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. All versions may crash after opening the attack code. However, there are a number of ways to limit the attack to an IE crash and prevent attacker code execution.

Disable JavaScript. Microsoft Security Advisory 979352 includes this workaround but we understand that this workaround significantly impacts usability of many Web sites.
Disable code executing from random locations of freed memory. Data Execution Prevention (DEP) prevents the execution of code from pages of memory that are not explicitly marked as executable. DEP is a supported feature on Windows XP Service Pack 2 and higher, Windows Server 2003 Service Pack 2 and higher, and all versions of Windows Vista, Windows Server 2008, and Windows 7. Some platforms enable DEP by default (see below). You can read more about DEP in this blog here and here. You can enable DEP on Windows XP and Windows Vista by clicking the Microsoft Fix It button below. (DEP is enabled by default for Internet Explorer 8 running on XP Service Pack 3, Windows Vista Service Pack 1 and higher, and Windows 7, so you do not need to use the "Microsoft Fix It" for those configurations.)

Note on enabling DEP for Windows Vista

The security advisory lists steps to enable DEP for Internet Explorer 7. To enable DEP on Windows Vista, be sure to run Internet Explorer as an Administrator (Right-click, and then select “Run as Administrator”). After enabling DEP, close the Internet Explorer session and re-launch Internet Explorer to browse with DEP enabled. The option will be grayed-out if you are not running Internet Explorer as an Administrator.

If you enable DEP on Windows Vista using the Microsoft Fix It, you will not see the Internet Explorer user interface change. However, after restarting Internet Explorer, you can use a tool like Process Explorer to verify that DEP is enabled. The Internet Explorer user interface displays value of a registry key while the Microsoft Fix It enables DEP by using an appcompat shim.

Acknowledgements

Big thanks to Chengyun Chu for his exploit analysis and risk assessment help. And thanks to Rob Hensing for the DEP research and FixIt4Me MSI help. Thanks to Fermin J. Serna for the vulnerability analysis. Lots of people at Microsoft are working on this, thanks everybody.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

January 12, 2010

Permalink for 'Security_Vulnerability_Research___Defense/2010/01/12/MS10_001__Font_file_decompression_vulnerability'

20:00

MS10-001: Font file decompression vulnerability

» ‎ Security Vulnerability Research & Defense

MS10-001 addresses a vulnerability (CVE-2010-0018 ) in the LZCOMP de-compressor for Microtype Express Fonts. This blog aims to answer some questions regarding the updates we’ve made in this area.

What is the issue?
t2embed.dll improperly performs bounds-checking on lengths which are decoded from the LZCOMP bit-stream. This made it possible for a copy loop to violate the intended working buffer.

Is the EOT functionality reachable through 3rd party code?
Yes, the t2embed library provides EOT functionality that can be used by 3rd party code. Many 3rd parties import t2embed for their font rendering, though some may choose to implement their own font rendering.

Why an Exploitability Index rating of 2?
The Exploitability Index rating or 2 is due to the low likelihood of successful exploitation. Hurdles exist around heap preparation and predictability, heap data corruption, and a race condition to get an exception handler making successful exploitation unlikely.

What is the likelihood of successful exploitation?
Due to the nature of bounds-checking performed in t2embed on 32-bit systems XP and later, the only buffer+index combinations which would pass the old checks will point into address 0x80000000 and above. Because these regions cannot be accessed while running at IOPL 3, the process will crash (Access Violate) and the attempt to run arbitrary code would fail.

On Windows 2000, this vulnerability could be abused to leverage code execution. On 32-bit platforms post Windows 2000, improper memory access would commonly be observed in the form of a Read Access Violation at address 0x80000000 or above, though the memory layout on /3GB-enabled systems could be manipulated to compromise the integrity of the hosting process. Stability (Denial of Service) implications exist on these systems when /3GB is not enabled (default), whereas /3GB-enabled systems run a risk of code execution, though no known attack vectors exist in Microsoft products.

Third party products which are (A) large address aware ([msdn.microsoft.com]), (B) consume the t2embed, and are (C) running on a /3GB-enabled system should be considered exploitable.

On 64-bit platforms, improper memory access would commonly be observed in the form of a Read Access Violation at a kernel mode address which would affect application stability (Denial of Service) with no threat of code-execution.

Here is a table to represent the exploitation scenarios described above:

	/2GB not running Large Address Aware Application	/3GB not running Large Address Aware Application	/2GB running Large Address Aware Application	/3GB running Large Address Aware Application
32-bit XP and newer	Denial of Service	Denial of Service	Denial of Service	Chance for Code Execution
64-bit XP and newer	Denial of Service	Denial of Service	Denial of Service	Denial of Service
Windows 2000	Chance for Code Execution	Chance for Code Execution	Chance for Code Execution	Chance for Code Execution

The Windows 2000 severity rating of critical was chosen due to the vulnerable code being exposed through client applications that can render EOT fonts in a way that does not require user interaction/notification. (such as Microsoft Internet Explorer, Microsoft Office PowerPoint, and Microsoft Office Word)

What are the attack vectors?
Remote attack vectors are all in user-mode:

Malicious fonts (EOT) delivered within files hosted on malicious web sites which are rendered in all versions of Internet Explorer by default.
Malicious office documents e-mailed to victims with social engineering to entice the victim to open the document which contains a malformed embedded font which would then be rendered upon opening the Office document (PowerPoint and Word documents are the most likely attack vectors).

How do I protect myself?
The best option for protecting against this vulnerability is to apply the update for MS10-001.

As stated in a previous SRD blog post, another option is to disable support for parsing/loading embedded fonts in IE. The side effect of this approach is that it will cause web sites which make use of embedded font technology to fail to render properly.

What is /3GB and how can I tell if /3GB is enabled on my system?
/3GB is a switch and it allows 32-bit systems to benefit from 3GB of addressable memory versus the default 2GB of memory. More information on /3GB can be found here. You can check to see whether you have /3GB enabled on your system by typing the following command in a shell:

C:>bcdedit.exe /v

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=D:
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {4a81cc63-2e99-11de-a190-00188b749f31}
resumeobject            {4a81cc62-2e99-11de-a190-00188b749f31}
displayorder            {4a81cc63-2e99-11de-a190-00188b749f31}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {4a81cc63-2e99-11de-a190-00188b749f31}
device                  partition=C:
path                    Windowssystem32winload.exe
description             Microsoft Windows Vista
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
bootdebug               Yes
osdevice                partition=C:
systemroot              Windows
resumeobject            {4a81cc62-2e99-11de-a190-00188b749f31}
nx                      OptIn
increaseuserva          3072
debug                   No

Note the increaseuserva variable. If unset (or set to 2048), you do not have /3GB enabled. If this value is set to 3072 (as seen here) you have /3GB enabled.

What is LZCOMP?
LZCOMP is a compression algorithm variation of the LZ77 theme. A great explanation of LZCOMP and how it differs from LZ77 can be found here.

Where does the LZCOMP de-compressor component reside on my system?
The LZCOMP de-compressor exists within the t2embed dynamically linked library. It commonly resides in %SystemRoot%System32 and is imported by programs such as Office and Internet Explorer.

How does this Fonts vulnerability differ from the previous Fonts vulnerability addressed by MS09-065?
This vulnerability exists in a user-mode component (t2embed.dll) whereas the previous Fonts vulnerability (MS09-065) addressed a kernel-mode component (win32k.sys).

I’d like to thank Matt Miller for general guidance, Bruce Dang and Robert Hensing from the MSRC Engineering Team for their efforts on this release.

-Brian Cavenah, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

← SecuriTeam.com SecurityFocus News →

SecurityFeed.info » Security Vulnerability Research & Defense

Feeds

Security Vulnerability Research & Defense (10 unread)