"Designing for security is important because an ActiveX control is particularly vulnerable to attack. An application running on any Web site can use the control; all that it needs is the control's class identifier (CLSID)."
http://msdn2.microsoft.com/en-us/library/aa752035(VS.85).aspx
The threat of malicious web sites abusing ActiveX objects already installed on client PCs is real, as confirmed by the above MSDN article, and numerous published vulnerabilities. In some instances, cached Java applets can be abused in the same way. Depending on what the code does, this problem can lead to some really nasty vulnerabilities in application logic.
An easy way to prevent ActiveX objects and Java applets from being misused by other web sites is to hard code the list of domains allowed to use the object in its own source. Unfortunately, in some cases this is not a feasible solution, as perhaps the code is meant to be hosted on multiple domains. Case in point, the MS RDP activex. Lots of web sites use this control to have a browser embedded remote desktop window.
Since we can't rely on the components to protect themselves from abuse, I think the browser should provide more protection. Why can't the browser sandbox the code such that only the web sites which installed them can actually invoke them? How hard is it to maintain an inventory of installed objects/applets and enforce access control lists for websites? Even in cases where mutltiple sites use the same control, a user controllable white-list could help protect against abuse. Users should be able to white-list web sites which are allowed to use the control, or white-list the control itself for all sites.
One particular Java applet I've analyzed employs a hard coded white list. The purpose of this applet is to launch a server specified executable file on the client computer. If a malicious web site were able to invoke this applet from the browsers cache, it could possibly launch an arbitrary executable. See the below code:
private static final String legalDomains[] = {
".domainA.com", ".domainB.com", ".domainC.com"
};
private boolean IsLegalDomain()
{
String browserDomain = getDocumentBase().getHost();
boolean securityException = false;
for(int i = 0; i <>
{
if(!browserDomain.endsWith(legalDomains[i]))
continue;
securityException = true;
break;
}
return securityException;
}
If the domain returned by the web browser is not in the hard coded white list, the applet will fail securely. Unfortunately, this would not stop a dedicated attacker; it would just force him or her to change their approach.
While this reduces the client side attack surface, it makes the white listed websites more of a target because they are trusted by the client. Without the white list, you could just own the client. With the white list, you need to own the domain in order to own the client. XSS, persistent XSS and other vulns that allow attackers to control site content should allow you to successfully attack the client side code.
Additionally, this opens the door for another client side vulnerability to be leveraged to exploit the vulnerable AX or applet code. DNS spoofing and CSRF based router attacks that lead to client DNS setting compromise can both lead to malicious code being hosted under trusted, white listed domains.
It is nothing new that client side code such as applets and AX objects greatly increase client side attack surface. What scares me is that it doesn't seem like software vendors are any less hesitant to use them. In fact, from the research I've been doing, it seems that vendors would generally opt for enhanced client side functionality (like auto launching EXE's) at the expense of security.
http://msdn2.microsoft.com/en-us/library/aa752035(VS.85).aspx
The threat of malicious web sites abusing ActiveX objects already installed on client PCs is real, as confirmed by the above MSDN article, and numerous published vulnerabilities. In some instances, cached Java applets can be abused in the same way. Depending on what the code does, this problem can lead to some really nasty vulnerabilities in application logic.
An easy way to prevent ActiveX objects and Java applets from being misused by other web sites is to hard code the list of domains allowed to use the object in its own source. Unfortunately, in some cases this is not a feasible solution, as perhaps the code is meant to be hosted on multiple domains. Case in point, the MS RDP activex. Lots of web sites use this control to have a browser embedded remote desktop window.
Since we can't rely on the components to protect themselves from abuse, I think the browser should provide more protection. Why can't the browser sandbox the code such that only the web sites which installed them can actually invoke them? How hard is it to maintain an inventory of installed objects/applets and enforce access control lists for websites? Even in cases where mutltiple sites use the same control, a user controllable white-list could help protect against abuse. Users should be able to white-list web sites which are allowed to use the control, or white-list the control itself for all sites.
One particular Java applet I've analyzed employs a hard coded white list. The purpose of this applet is to launch a server specified executable file on the client computer. If a malicious web site were able to invoke this applet from the browsers cache, it could possibly launch an arbitrary executable. See the below code:
private static final String legalDomains[] = {
".domainA.com", ".domainB.com", ".domainC.com"
};
private boolean IsLegalDomain()
{
String browserDomain = getDocumentBase().getHost();
boolean securityException = false;
for(int i = 0; i <>
{
if(!browserDomain.endsWith(legalDomains[i]))
continue;
securityException = true;
break;
}
return securityException;
}
If the domain returned by the web browser is not in the hard coded white list, the applet will fail securely. Unfortunately, this would not stop a dedicated attacker; it would just force him or her to change their approach.
While this reduces the client side attack surface, it makes the white listed websites more of a target because they are trusted by the client. Without the white list, you could just own the client. With the white list, you need to own the domain in order to own the client. XSS, persistent XSS and other vulns that allow attackers to control site content should allow you to successfully attack the client side code.
Additionally, this opens the door for another client side vulnerability to be leveraged to exploit the vulnerable AX or applet code. DNS spoofing and CSRF based router attacks that lead to client DNS setting compromise can both lead to malicious code being hosted under trusted, white listed domains.
It is nothing new that client side code such as applets and AX objects greatly increase client side attack surface. What scares me is that it doesn't seem like software vendors are any less hesitant to use them. In fact, from the research I've been doing, it seems that vendors would generally opt for enhanced client side functionality (like auto launching EXE's) at the expense of security.
No comments:
Post a Comment