IE 7 and 8 Default Security Leaves Intranets At RiskIE 7 and 8 Default Security Leaves Intranets At Risk
Researcher details attacks on intranets that abuse Internet Explorer 7 and 8 security default settings
April 13, 2009
Internet Explorer 7 and 8's default security settings can be unsafe for internal, intranet-based Web applications, according to newly published research.
Cesar Cerrudo, founder and CEO of Argeniss, a security consulting firm in Argentina, has demonstrated that IE's default features for intranet "zones" can be abused to wage attacks on internal Web applications both from the outside and from within the organization. Cerrudo has released his findings, which show how default settings can be used both to detect and exploit vulnerabilities in intranet applications.
The attacks take advantage of the fact that local intranet zone settings are inherently more trusted than ones in the Internet zone. But Internet-facing Web apps are basically safe from these attacks: "IE Internet zone settings are stronger, and they will prevent and mitigate most of the attacks," he says.
Microsoft was not available for comment at the time of this posting.
Researchers previously have demonstrated attacks on intranets using internal host scanning and attacks on internal hosts, for instance, he says, but not the type of practical cross-site scripting, SQL injection, and cross-site request forgery attacks on these intranet apps from the Internet that he is demonstrating with IE. "All [of] this is done from the Internet, abusing Internet Explorer's weak default-security settings," Cerrudo says.
One of the first big revelations of how vulnerable intranets can be came at Black Hat USA in 2006, when Jeremiah Grossman and Robert "RSnake" Hansen demonstrated how Java Script-based attacks against Websites could also be used to hack internal Web apps using XSS.
"Cesar is expounding upon the research and making it IE-specific, [with] more and better examples of how attacks could happen," says Grossman, CTO at WhiteHat Security.
Cerrudo's research points out how IE 7 and 8's default security settings in the so-called Local Intranet Zone are more "relaxed" than the ones in the Internet zone. According to Cerrudo, the weak default settings are: automatic logon in the intranet zone; Websites with fewer privileges can reach this zone; script-initiated windows are allowed regardless of their size or position; Websites can open windows with an address or status bar; and Version 8's XSS filter is disabled by default.
These features in various instances and combinations leave intranet-based apps vulnerable to phishing, cross-site scripting and SQL injection-combination attacks, and cross-site request forgery attacks, for instance. An attacker could perform these attacks to steal, modify, or wipe out data on a server, as well as take over a server altogether, according to the research.
Cerrudo says the attacks he has demonstrated require some insider information on the targeted internal Web-based applications. "I demonstrate practical intranet Web application attacks that only require some insider information -- Web applications information -- and also how to detect vulnerabilities in order to exploit them," he says.
"All of [these] attacks are dangerous. The result of the attacks go from hosts/servers/network compromises to data being stolen, deleted, modified, etc.," he says.
So how can organizations protect their intranet apps from such attacks? Cerrudo says first, be sure intranet Web apps are secure and free of vulnerabilities that can be exploited. Also, change IE default security settings, although that isn't necessarily straightforward: "This can cause problems to users since some functionality could break, browsing experience won't be nicer, etc.," he says. "I would set intranet zone settings the same as default Internet zone settings. If this causes problems with some Websites, then these Websites could be added to Trusted Sites security zone and set in that zone the needed settings."
WhiteHat's Grossman says changing the settings is worth any headache it will cause. "While it would break certain use-cases, I think it's worth it," Grossman says. "Do not [automatically] allow connections to the intranet originated from Internet Web pages. Make users explicitly allow it."
Meanwhile, Cerrudo says it would be helpful if IE supported custom security zones. "Something that IE is lacking is allowing the user to create custom security zones where Websites can be added and security settings can be set based on specific needs," he says.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.
About the Author(s)
You May Also Like
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication MethodsOct 26, 2023
Modern Supply Chain Security: Integrated, Interconnected, and Context-DrivenNov 06, 2023
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023
Passwords Are Passe: Next Gen Authentication Addresses Today's Threats
How to Deploy Zero Trust for Remote Workforce Security
What Ransomware Groups Look for in Enterprise Victims
How to Use Threat Intelligence to Mitigate Third-Party Risk
Concerns Mount Over Ransomware, Zero-Day Bugs, and AI-Enabled Malware