1. Wifi Security -or- Descending Into Depression and Drink Mike Kershaw / Dragorn [email_address]

4. Multiple data encodings depending on spec (11b/a/g/n)

5. All fundamentally spread-spectrum

6. This means we can interact with it easily

8. Generic Wifi card (Alfa 11g is cheap to start with)

9. Support in the OS (more on this later)

10. Total cost of ownage: $50 or so

12. By “we” I mean “security professionals”

13. But even “the great unwashed” are clueing in, kind of. Encryption on home nets is up

15. WPA-Enterprise

16. Per-user authentication

17. Per-user keying

18. Mutual auth via certificates

20. AES used in WPA-CCMP as yet unbroken

21. TKIP showing flaws, but is already past sell-by date, move to CCMP

23. Opportunities for failure exist if users don't validate certs (or are allowed to say 'ok')

24. TKIP will eventually fall

26. Best defense: Strong network architecture (again, WPA)

27. Monitoring for conflicting or spoofed access points

28. Client protection attempts to defend known good users

30. Defending clients on a strong network is easy since the AP controls crypto

31. Defending clients on open AP is very hard

33. Spoof AP, tell all clients to disconnect

34. Pure channel denial (flood channel with noise)

35. “ Crowbar” defense – find the person doing it and hit them with a crowbar.

37. Management frames are totally unprotected

38. Open networks are un-authenticateable

39. It's shared media

41. Users are – typically – bad decision makers

42. The OS doesn't help: It likes to join networks it's seen before

43. It's hard to tell what's real, assuming the user even looks

46. Who wouldn't want to join “ Free Public Wi-Fi ”?

47. Once, long ago, this network probably existed

48. When windows can't find a network, it likes to make an ad-hoc version...

49. Then someone else tries to join

51. Unless, say, someone brought up a network with the same name...

52. … And handed out IP addresses...

53. Which would get us LAN access to the system

54. But that would never happen, right?

56. If you say you're network Foo , you must be, right?

57. It's very hard to avoid really bad behavior as a user

58. Roaming sure looks a lot like spoofing

60. Client assumes the SSID is a common network

61. Roams to the strongest signal

62. Data handoff responsibility of backend (controller or common L2 network)

63. Only differentiator is MAC addr

66. You may not be talking to who you think you're talking to

67. So long as the packets go through, the user never knows

68. Man in the middle = Win

70. Interface 1 connects to legitimate network (any network, or cell data, or...)

71. Interface 2 provides spoofed “Free Public Wifi” network.. or rhymes with “FarDucks”.. or...

73. Session cookies, data, etc vuln

74. “ The Middler”, SSLSniff, Cookie Monster

75. Hijack sessions via MITM

77. Why? They're really obvious.

78. Might still get some users, but it'll be pretty blatant

79. Points ARE awarded for style. Or at least, for stealth.

81. We just found the best time machine ever !

83. And not some hippy do-gooder time machine, either

85. But one where we get to bring back weapons from the future

88. Unswitched shared media Ethernet...

89. Sniffing the entire segment …

90. TCP session hijacking...

92. Right ?

93. People have to have gotten smarter by now...

94. You'd never take a system from a secure network to an insecure network, right ?

97. The gym

98. A hotel

99. Bookstores

100. McDonalds

101. … shmoocon?

103. Open networks have no client protection

104. Nothing stops us from spoofing the AP and talking directly to a client!

106. By generating an 802.11 header FROM the AP and TO the client

107. The client thinks the packet is legit

108. The AP has no opportunity to act on it

109. We can communicate directly with “protected” clients on open networks

111. Writing custom code for each driver sucks

112. Writing apps for each OS sucks

113. Hopefully LORCON doesn't suck

115. New API modeled off of PCAP

116. Designed to be really easy to use

117. C, Ruby API

118. Will soon support all the cards LORCON1 did, for now, Linux

119. http://802.11ninja.net

121. Automatically configures virtual network interfaces and sets up modes for injection

122. Send arbitrary bytes -or- use packet assembly API

124. About 5 years ago, Toast debuted Airpwn at defcon

125. TCP stream hijacking on 802.11

126. Why hasn't everyone been using this !?

127. Not just for shock-porn anymore!

130. TCP is only “secure” because the seq/ack is unknown

131. Attacker sees your L2, so seqno is known

132. Any TCP stream subject to abuse

134. Client -> Server “GET /foo.html HTTP/1.0” Seq 123 ack 10

135. Server ← Client “HTTP headers, content” Seq 10 ack 189

137. Racket packet assembly (high speed Ruby packet assembly)

138. Ruby PCAP

139. And a little TLC

141. Client -> Server “GET /foo.html HTTP/1.0” [seq/ack]

142. MSF ← Client “Malicious data...” [seq/ack]

143. MSF ← Client FIN!

144. MSF -> Server FIN! [using client seq/ack]

145. Server ← Client “Real data!” [old seq/ack]

146. MSF msf > use auxiliary/spoof/wifi/airpwn msf auxiliary(airpwn) > set INTERFACE alfa0 INTERFACE => alfa0 msf auxiliary(airpwn) > set RESPONSE "Airpwn - MSF!" RESPONSE => Airpwn – MSF! msf auxiliary(airpwn) > run

147. MSF msf auxiliary(airpwn) > run [*] AIRPWN: Response packet has no HTTP headers, creating some. [*] Auxiliary module execution completed msf auxiliary(airpwn) > [*] AIRPWN: 10.10.100.42 -> 208.127.144.14 HTTP GET [/files/racket/src/doc/] TCP SEQ 542050816

149. Response can be full JS, image replacement, HTML, a file

150. Sitelist YAML file for matching specific requests (poison lists of known files, like jquery)

152. Complete attacker control of page content including headers , too

154. HTTP content replacement

156. Control over forms

157. Control over the browser in general

158. Access to anything in the security context of the compromised page

160. What do we do now?

161. Nearly all complex sites include a pile of javascript helper files

162. What happens if we replace one of those ?

163. It's not news, it's Javascript

165. Totally invisible to the user

166. Multiple requests = Multiple opportunities to land attack

167. Run in same privilege domain as web page

169. DOM = Document Object Model

170. Programmatic manipulation of page content

171. Once in the DOM we can do ANYTHING

173. It's not stupid, it's advanced var embeds = document.getElementsByTagName('div'); for(var i=0; i < embeds.length; i++){ if (embeds[i].getAttribute(&quot;class&quot;) == &quot;cnnT1Img&quot;) { embeds[i].innerHTML = &quot;...&quot;; } else if (embeds[i].getAttribute(&quot;class&quot;) == &quot;cnnT1Txt&quot;) { embeds[i].innerHTML = &quot;...&quot;; }}

175. Rewrite all FORMs to proxy through us? Sure.

176. Rewrite all HTTPS to HTTP so we can capture logins and “secure” data? Yup!

177. Poison content topical to a conference? Tin foil hat, but yes!

178. HTTP not so S var refs = document.getElementsByTagName('a'); for (var i = 0; i < refs.length; i++){ var rval = refs[i].getAttribute(&quot;href&quot;); if (rval == null) { continue; } refs[i].setAttribute(&quot;href&quot;, rval.replace(/^https:/, &quot;http:&quot;); }

180. A lot .

181. No, seriously.

183. Attack HTTP clients via cache control

184. Layer 2 attacks against web content can be made persistent

185. That means once you leave... you're still owned

187. Browsers have cache

188. Cache, by nature, remains around

189. Users don't notice

190. If I own your TCP session, I own your cache control

192. That file remains in their cache

193. And is re-used when they revisit that site

194. From inside the secure office network (or wherever)

195. Don't think it's a problem?

197. So we hijack a common JS file

198. Spike it with malicious code

199. Set it to cache

200. Now when the user goes back to work and goes to twitter again...

202. Browser will keep this and re-use it every time until it expires

203. Iframes? Kaminsky socket/sucket? Load new browser exploits?

204. But a user would never go to Twitter at work, right?

206. Hosted off the same URL at google?

207. What happens when we poison the url?

208. We get script execution on every site using it

210. Maybe no good attacks in the browser this week?

211. Wait for a browser 0day then flip the switch to include malware

212. Every system that has the cached call-home is attacked as soon as the users visit the poisoned site

214. Websites that don't ask for logins are just as capable of feeding browser exploits

215. Any website can be poisoned with browser-owning code

217. Not really, users still have to be smart enough to not accept a bad cert

218. And users would never do something insecure, right?

219. OBVIOUSLY that pop star wants me to see her naked!

226. But we're technical people

227. “ Signed by VeriSign” vs “Signed by Verisign” “Verisign” vs “Verisign”?

228. Assuming a user even looks and doesn't just click “OK”

229. Users just want the web

230. “ Click OK until porn”

232. I use a VPN! -or-

233. I force my users to use a VPN via user management!

234. This won't work against me!

236. Except your browser has no concept of security domains

237. What was cached in an insecure domain will remain for a secure domain

239. Many first-stage landers are not encrypted

240. Unencrypted page on open network? Perfect target

242. Then the attacker can control your browser...

243. Iframes? Pop-under windows? Ajax queries dumped to nowhere?

245. Request page in the background

246. Cache spiked page (which the victim never saw)

248. Compare content with signature for attack

249. Request again if attack didn't land

250. Now we own arbitry sites in cache PRE-VPN

252. So if the attacker controls L2...

254. Sure can!

255. Race the DNS server!

256. Wait for a DNS query, then...

257. Set a QR flag on the request and supply our own response

259. YAML config to match multiple queries with different responses

260. Races DNS server to give user a “custom” IP

262. We control DNS resolution

263. We can re-try as quickly as we want thanks to a JS script that watches for success...

264. What stops us from caching http://intranet/

266. How about a shim that ships your internal pages off to a remote server once you're on VPN?

267. Or just rewrites all your form DOMs to proxy out?

269. Speed of user experience is the biggest concern...

270. So lets cache DNS in the browser, too!

271. So this means...?

273. Post-VPN site control thanks to guessed internal DNS names being cached as external servers

274. “Mobile Convergence”

276. Complex browsers

277. Lower bandwidth networks

278. Yup, very happy to cache data

280. I'll just use 3G!

281. You can't see me there!

282. True...

288. Some prefer it – power / speed / data limits

289. Besides, we could “help” them along...

292. You should NOT buy illegal cell phone jammers to force victims to use wifi

293. And of course someone trying to own your company wouldn't do something illegal , right?

295. Better MSF integration with other L2 attacks

296. Dynamic content generation based on target

297. Integration with browser autopwn

299. It's much harder to defend clients

300. Especially when they go off into the world onto insecure APs

302. Sites you think you trust, you can't

303. Spiked attacks can stay resident in the browser

304. Your users might be bringing something back with them

306. Normal users don't stand a chance

307. You may already be screwed

308. I warned you this would be depressing...

310. Easy for US

311. Hard for most users

312. Hard to enforce: Users don't like barriers between them and internet

314. Mandate updates (easier said than enforced)

315. Forbid users from taking laptops onto open networks (policy, UAC, don't give out laptops?)

317. WPA-PSK? Better but not a solution.

318. WPA-EAP? Better still, even with the same user/password you get per-user keying

320. If cert is signed by a common CA, easy to get another from the same CA

321. If cert is signed by self-sign CA user has to accept

322. Up to user to determine valididy

323. Not what users are good at

325. Some vendors try to solve it with custom clients

326. Ties into specific OS then

327. Running foreign binaries

328. No really good solution yet

330. Use different browsers for login and normal use

331. Manually clear cache

332. Never keep windows open between security domains

333. Still scary, forget once and you're screwed

335. HDM

336. Toast

337. Renderman

338. Jesse Burns

339. Everyone else who has listened to me rant about this

341. Kismet @ www.kismetwireless.net

342. MSF @ metasploit.com

343. Me @ dragorn@kismetwireless.net