Microsoft Internet Explorer 8/9 – Steal Any Cookie

Exploit Database
128 阅读

作者： Christian Haider

日期： 2013-01-28
类别：
- webapps
平台：
- windows
来源：https://www.exploit-db.com/exploits/24432/

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

# Exploit Title: Internet Explorer 8 & Internet Explorer 9 steal any Cookie

# Date: 27.01.2013

# Exploit Author: Christian Haider; Email: christian.haider.poc @ gmail

*dot* com; linkedin: http://www.linkedin.com/in/chrishaider

# Category: remote

# Vendor Homepage: http://www.microsoft.com

# Version: IE 8, IE 9

# Tested on: Windows 7, Windows XP

# CVE : CVE-2013-1451

Disclaimer

----------

The information in this advisory and any of its demonstrations is provided

"as is" without any warranty of any kind. I am not liable for any direct or

indirect damages caused as a result of using the information or

demonstrations provided in any part of this advisory. Educational use

only..!!

----------

This vulnerability regarding Internet Explorer 8 & 9 was reported to

Microsoft in December 2011 (ID is [12096gd]). Although the vulnerability

can be used to steal cookies it has not been rated as a high risk

vulnerability. As a consequence of that we will never see an update for IE

8 & IE 9 and rather have to wait for a fix in IE 10. Only requirement for a

successful exploit is that IE uses the same proxy for HTTP and HTTPS.

I consider this a high risk vulnerability and a simple configuration change

could mitigate the risk. To make the public aware of this threat I made

this vulnerability public.

CVE-ID has not been issued yet.

Vulnerability discovered by: Christian Haider; Email: christian.haider.poc

@ gmail *dot* com

Linkedin: http://www.linkedin.com/in/chrishaider

PoC Video on Youtube = http://www.youtube.com/watch?v=TPqagWAvo8U

PoC Files:

- info.php = http://pastebin.com/download.php?i=bPDDwJY4

<?php

print_r($_SERVER['HTTP_HOST']);

echo '<br/>';

// A way to view all cookies

//print_r($_COOKIE);

$cookie=$_COOKIE;

foreach ($cookie as $key=>$val)

echo "$key--> HIDDEN; ";

- video.html = http://pastebin.com/download.php?i=KXYX3pv1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

</head>

<body>

Facebook.com

</form>

Google.com

</form>

https://www.google.com

</form>

<br/>

<br/>

<br/>

<br/>

<br/>

</body>

</html>

- script.js (empty file)

Timeline:

Discovered (12.12.2011)

Reported to Vendor (16.12.2011)

Confirmed by Vendor (09.01.2012)

Proof of Concept (27.01.2013)

Made Public (28.01.2013)

After a short walkthrough of the setup I will demonstrate the result.

1. Install a proxy server of your choice. We use squid for now.

2. Install a webserver. We use apache for now.

a. Make the webserver listen for http traffic on port 80

b. Make the webserver listen for https traffic on the same port as the

proxy does. In our example Squid works on 443

3. Due to the lack of an approved certificate for our website we have to

import the https certificate into our key store. If you got a public

hostname and a certificate for than it this step is not necessary

4. Let�s check that the client and the proxy resolve the hostnames to the

correct IP addresses (web01.local.home, web02.local.home, www.google.com,

www.facebook.com, and so on)

5. Setup a website with lots of data to be fetched from our https website.

The result is that lots of connections get established

6. After that we request some data from the actual target website. In our

example we use Facebook, linkedin, dropbox, �

7. As you can see in our example we send all cookies to the wrong website

and display the data using a php script. I do only show the names of the

cookies instead of the actual data but be assured that the whole cookie

gets sent

8. This is not limited to external websites. Even cookies used inside a

company can get stolen the very same way. Imagine you use SAML to

authenticate to Office 365 or other SaaS products.

9. This works out of the box with XP and apache. Windows 7 does include the

hostname in each request and apache does check this field [RFC 6066].

10. You have to customize and build apache to remove that check.

Nevertheless the actual information was sent on Windows 7 as well. After

all this check is carried out on the webserver.

11. Let�s ping the proxy and do a single post so we can narrow in once we

analyze the traffic

12. One even scarier thing happens if you do the following. First open our

special crafted website. Then move on to https://www.google.com; afterwards

open another website like http://virusscan.jotti.org/info.php

13. As you can see IE thinks it is connected securely but when you have a

closer look than you will see that IE thinks it is connected to

www.google.com but it ended up on our webserver

14. Sometimes IE crashed once you close it after you played around with

this website which might indicate that there are some loose references or

other vulnerabilities you could exploit

Analyze what happens:

=====================

How ends that data up being sent to the wrong webserver?

First we have a look what our special crafted website looks like. You will

see it is not that special.

We have 3 forms with a submit button and several includes of script.js

followed by several iframes of info.php;

The last 5 iframes are to facebook, google, linkedin, and so on.

What we expect IE to carry out:

1. Get our crafted website

2. Build https connection and download script.js from

https://web01.local.home:8080

3. Build https connection and download info.php from

https://web01.local.home:8080

4. Use a normal connection to download content from facebook, google,

linkedin, and so on

We use wireshark to have a look if that is true:

1. We see the GET of our crafted website and the unencrypted traffic which

says nothing has changed

2. We see 12 connect for the 39 requests over https. That means we reuse

the connections!

3. Search for any other GET or POST which should be unencrypted --> There

are no

4. What happened to the requests? Let�s have a look at the very end. Right

after we started the ping command, there should be a request

5. It is tunneled over the https connection which ends at our crafted

website

Conclusion: After several connections are opened IE starts to reuse them.

Unfortunately it seems that the proxy component of IE does not keep track

of the actual target of the connections.

This results in GET/POST REQUEST getting tunneled through an SSL connection

to the wrong webserver.

The proxy server does not even see what is going on within the SSL

connection so there is nothing it could do to prevent it. This might be

different if you scan inside of the SSL connection. RFC 6066 section 11.1

specifies that web servers MUST check that the host header and host name

sent via SNI match but does a proxy scan for such malfunction?