Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/13/2009
02:54 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

IE 7 and 8 Default Security Leaves Intranets At Risk

Researcher details attacks on intranets that abuse Internet Explorer 7 and 8 security default settings

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. Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19551
PUBLISHED: 2019-12-06
In userman 13.0.76.43 through 15.0.20 in Sangoma FreePBX, XSS exists in the User Management screen of the Administrator web site. An attacker with access to the User Control Panel application can submit malicious values in some of the time/date formatting and time-zone fields. These fields are not b...
CVE-2019-19552
PUBLISHED: 2019-12-06
In userman 13.0.76.43 through 15.0.20 in Sangoma FreePBX, XSS exists in the user management screen of the Administrator web site, i.e., the/admin/config.php?display=userman URI. An attacker with sufficient privileges can edit the Display Name of a user and embed malicious XSS code. When another user...
CVE-2019-19620
PUBLISHED: 2019-12-06
In SecureWorks Red Cloak Windows Agent before 2.0.7.9, a local user can bypass the generation of telemetry alerts by removing NT AUTHORITY\SYSTEM permissions from a malicious file.
CVE-2019-19625
PUBLISHED: 2019-12-06
SROS 2 0.8.1 (which provides the tools that generate and distribute keys for Robot Operating System 2 and uses the underlying security plugins of DDS from ROS 2) leaks node information due to a leaky default configuration as indicated in the policy/defaults/dds/governance.xml document.
CVE-2019-19627
PUBLISHED: 2019-12-06
SROS 2 0.8.1 (after CVE-2019-19625 is mitigated) leaks ROS 2 node-related information regardless of the rtps_protection_kind configuration. (SROS2 provides the tools to generate and distribute keys for Robot Operating System 2 and uses the underlying security plugins of DDS from ROS 2.)