Wifi Security, or Descending into Depression and Drink

2,296 views

Published on

Published in: Education, Technology
  • SecurityTube now has a certification based on their wireless videos: http://securitytube-training.com/certifications/securitytube-wi-fi-security-expert/ Testimonials look good.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Wifi Security, or Descending into Depression and Drink

  1. 1. Wifi Security -or- Descending Into Depression and Drink Mike Kershaw / Dragorn [email_address]
  2. 3. 802.11 <ul><li>2.4 and 5.8 GHz
  3. 4. Multiple data encodings depending on spec (11b/a/g/n)
  4. 5. All fundamentally spread-spectrum
  5. 6. This means we can interact with it easily </li></ul>
  6. 7. Packing your bags <ul><li>Unlike frequency-hopping protocols, trivial to capture 802.11
  7. 8. Generic Wifi card (Alfa 11g is cheap to start with)
  8. 9. Support in the OS (more on this later)
  9. 10. Total cost of ownage: $50 or so </li></ul>
  10. 11. I come not to bury 802.11... <ul><li>We've got a pretty good idea about 802.11 security by now
  11. 12. By “we” I mean “security professionals”
  12. 13. But even “the great unwashed” are clueing in, kind of. Encryption on home nets is up </li></ul>
  13. 14. Secure configurations <ul><li>WiFi is secure in proper deployments
  14. 15. WPA-Enterprise
  15. 16. Per-user authentication
  16. 17. Per-user keying
  17. 18. Mutual auth via certificates </li></ul>
  18. 19. Strong encryption <ul><li>We've got a pretty solid crypto system
  19. 20. AES used in WPA-CCMP as yet unbroken
  20. 21. TKIP showing flaws, but is already past sell-by date, move to CCMP </li></ul>
  21. 22. “Done Properly” <ul><li>WPA-Enterprise secure “done correctly”
  22. 23. Opportunities for failure exist if users don't validate certs (or are allowed to say 'ok')
  23. 24. TKIP will eventually fall </li></ul>
  24. 25. 802.11 AP Defense <ul><li>We've been doing this for a long time now
  25. 26. Best defense: Strong network architecture (again, WPA)
  26. 27. Monitoring for conflicting or spoofed access points
  27. 28. Client protection attempts to defend known good users </li></ul>
  28. 29. Client Protection <ul><li>Inter-client traffic can be blocked at the AP
  29. 30. Defending clients on a strong network is easy since the AP controls crypto
  30. 31. Defending clients on open AP is very hard </li></ul>
  31. 32. Denial of Service Attacks <ul><li>Management frames unprotected
  32. 33. Spoof AP, tell all clients to disconnect
  33. 34. Pure channel denial (flood channel with noise)
  34. 35. “ Crowbar” defense – find the person doing it and hit them with a crowbar. </li></ul>
  35. 36. Punching 802.11 in the gut <ul><li>Absurdly easy
  36. 37. Management frames are totally unprotected
  37. 38. Open networks are un-authenticateable
  38. 39. It's shared media </li></ul>
  39. 40. Strangers with candy <ul><li>Avoiding hostile networks requires smart users
  40. 41. Users are – typically – bad decision makers
  41. 42. The OS doesn't help: It likes to join networks it's seen before
  42. 43. It's hard to tell what's real, assuming the user even looks </li></ul>
  43. 45. Going viral <ul><li>Users like free wi-fi
  44. 46. Who wouldn't want to join “ Free Public Wi-Fi ”?
  45. 47. Once, long ago, this network probably existed
  46. 48. When windows can't find a network, it likes to make an ad-hoc version...
  47. 49. Then someone else tries to join </li></ul>
  48. 50. Sore throats <ul><li>Of course, this junk ad-hoc network doesn't go anywhere
  49. 51. Unless, say, someone brought up a network with the same name...
  50. 52. … And handed out IP addresses...
  51. 53. Which would get us LAN access to the system
  52. 54. But that would never happen, right? </li></ul>
  53. 55. Being too trusting <ul><li>Clients are really trusting
  54. 56. If you say you're network Foo , you must be, right?
  55. 57. It's very hard to avoid really bad behavior as a user
  56. 58. Roaming sure looks a lot like spoofing </li></ul>
  57. 59. 802.11 Roaming <ul><li>Multiple AP with same SSID
  58. 60. Client assumes the SSID is a common network
  59. 61. Roams to the strongest signal
  60. 62. Data handoff responsibility of backend (controller or common L2 network)
  61. 63. Only differentiator is MAC addr </li></ul>
  62. 65. The packets must flow <ul><li>So if an attacker has a stronger radio than the AP...
  63. 66. You may not be talking to who you think you're talking to
  64. 67. So long as the packets go through, the user never knows
  65. 68. Man in the middle = Win </li></ul>
  66. 69. Stuck in the middle with... <ul><li>Dual-interface attacker
  67. 70. Interface 1 connects to legitimate network (any network, or cell data, or...)
  68. 71. Interface 2 provides spoofed “Free Public Wifi” network.. or rhymes with “FarDucks”.. or... </li></ul>
  69. 72. More Man-in-the-middle <ul><li>Many sites encrypt login, but not session
  70. 73. Session cookies, data, etc vuln
  71. 74. “ The Middler”, SSLSniff, Cookie Monster
  72. 75. Hijack sessions via MITM </li></ul>
  73. 76. This bores me <ul><li>All of these attacks are really pretty boring
  74. 77. Why? They're really obvious.
  75. 78. Might still get some users, but it'll be pretty blatant
  76. 79. Points ARE awarded for style. Or at least, for stealth. </li></ul>
  77. 80. So wait... <ul><li>Didn't we say 802.11 is shared media !?
  78. 81. We just found the best time machine ever ! </li></ul>
  79. 83. And not some hippy do-gooder time machine, either
  80. 85. But one where we get to bring back weapons from the future
  81. 87. The bad old days <ul><li>Hair metal, grunge, ripped jeans
  82. 88. Unswitched shared media Ethernet...
  83. 89. Sniffing the entire segment …
  84. 90. TCP session hijacking... </li></ul>
  85. 91. That's too easy <ul><li>It'd never be that easy, right?
  86. 92. Right ?
  87. 93. People have to have gotten smarter by now...
  88. 94. You'd never take a system from a secure network to an insecure network, right ? </li></ul>
  89. 96. Mmm, latte <ul><li>… and airports
  90. 97. The gym
  91. 98. A hotel
  92. 99. Bookstores
  93. 100. McDonalds
  94. 101. … shmoocon? </li></ul>
  95. 102. Making a mess <ul><li>Management frames have no protection
  96. 103. Open networks have no client protection
  97. 104. Nothing stops us from spoofing the AP and talking directly to a client! </li></ul>
  98. 105. No protection <ul><li>AP may try to filter inter-client communication by blocking packets when they hit the AP
  99. 106. By generating an 802.11 header FROM the AP and TO the client
  100. 107. The client thinks the packet is legit
  101. 108. The AP has no opportunity to act on it
  102. 109. We can communicate directly with “protected” clients on open networks </li></ul>
  103. 110. Making it easy: LORCON <ul><li>Writing the same injection code for every app sucks
  104. 111. Writing custom code for each driver sucks
  105. 112. Writing apps for each OS sucks
  106. 113. Hopefully LORCON doesn't suck </li></ul>
  107. 114. LORCON2 <ul><li>Unfortunately... the LORCON1 API... kind of sucked
  108. 115. New API modeled off of PCAP
  109. 116. Designed to be really easy to use
  110. 117. C, Ruby API
  111. 118. Will soon support all the cards LORCON1 did, for now, Linux
  112. 119. http://802.11ninja.net </li></ul>
  113. 120. Super simple <ul><li>Automatically determines the driver
  114. 121. Automatically configures virtual network interfaces and sets up modes for injection
  115. 122. Send arbitrary bytes -or- use packet assembly API </li></ul>
  116. 123. The inspiration <ul><li>Wifi session hijacking
  117. 124. About 5 years ago, Toast debuted Airpwn at defcon
  118. 125. TCP stream hijacking on 802.11
  119. 126. Why hasn't everyone been using this !?
  120. 127. Not just for shock-porn anymore! </li></ul>
  121. 129. Rerouting streams <ul><li>Typical layer2 attack
  122. 130. TCP is only “secure” because the seq/ack is unknown
  123. 131. Attacker sees your L2, so seqno is known
  124. 132. Any TCP stream subject to abuse </li></ul>
  125. 133. Anatomy of a session <ul><li>Handshake
  126. 134. Client -> Server “GET /foo.html HTTP/1.0” Seq 123 ack 10
  127. 135. Server ← Client “HTTP headers, content” Seq 10 ack 189 </li></ul>
  128. 136. So lets add this to MSF <ul><li>Lorcon Ruby wrapper
  129. 137. Racket packet assembly (high speed Ruby packet assembly)
  130. 138. Ruby PCAP
  131. 139. And a little TLC </li></ul>
  132. 140. Anatomy of an Evil session <ul><li>Handshake
  133. 141. Client -> Server “GET /foo.html HTTP/1.0” [seq/ack]
  134. 142. MSF ← Client “Malicious data...” [seq/ack]
  135. 143. MSF ← Client FIN!
  136. 144. MSF -> Server FIN! [using client seq/ack]
  137. 145. Server ← Client “Real data!” [old seq/ack] </li></ul>
  138. 146. MSF msf > use auxiliary/spoof/wifi/airpwn msf auxiliary(airpwn) > set INTERFACE alfa0 INTERFACE => alfa0 msf auxiliary(airpwn) > set RESPONSE &quot;Airpwn - MSF!&quot; RESPONSE => Airpwn – MSF! msf auxiliary(airpwn) > run
  139. 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
  140. 148. Fine-tuning <ul><li>Match & replace in regex
  141. 149. Response can be full JS, image replacement, HTML, a file
  142. 150. Sitelist YAML file for matching specific requests (poison lists of known files, like jquery) </li></ul>
  143. 151. Autogen <ul><li>Airpwn-MSF automatically generates HTTP headers as needed
  144. 152. Complete attacker control of page content including headers , too </li></ul>
  145. 153. Ill-gotten profit <ul><li>What does that get us?
  146. 154. HTTP content replacement </li></ul>
  147. 155. Or in other words... <ul><li>Control over the page DOM
  148. 156. Control over forms
  149. 157. Control over the browser in general
  150. 158. Access to anything in the security context of the compromised page </li></ul>
  151. 159. Obviously scripted <ul><li>So we can replace content...
  152. 160. What do we do now?
  153. 161. Nearly all complex sites include a pile of javascript helper files
  154. 162. What happens if we replace one of those ? </li></ul>
  155. 163. It's not news, it's Javascript
  156. 164. JS Fragments <ul><li>Especially attractive
  157. 165. Totally invisible to the user
  158. 166. Multiple requests = Multiple opportunities to land attack
  159. 167. Run in same privilege domain as web page </li></ul>
  160. 168. I'm in your browser <ul><li>Rewriting your DOM
  161. 169. DOM = Document Object Model
  162. 170. Programmatic manipulation of page content
  163. 171. Once in the DOM we can do ANYTHING </li></ul>
  164. 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;; }}
  165. 174. DOM is tasty <ul><li>What else can we do?
  166. 175. Rewrite all FORMs to proxy through us? Sure.
  167. 176. Rewrite all HTTPS to HTTP so we can capture logins and “secure” data? Yup!
  168. 177. Poison content topical to a conference? Tin foil hat, but yes! </li></ul>
  169. 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;); }
  170. 179. This really matters <ul><li>This matters
  171. 180. A lot .
  172. 181. No, seriously. </li></ul>
  173. 182. Persistence pays off <ul><li>Who has read rsnake's VPN paper?
  174. 183. Attack HTTP clients via cache control
  175. 184. Layer 2 attacks against web content can be made persistent
  176. 185. That means once you leave... you're still owned </li></ul>
  177. 186. Fast cache <ul><li>Short version of the VPN paper:
  178. 187. Browsers have cache
  179. 188. Cache, by nature, remains around
  180. 189. Users don't notice
  181. 190. If I own your TCP session, I own your cache control </li></ul>
  182. 191. Fast cache <ul><li>Client is fed a spiked JS file with cache set to 10 years
  183. 192. That file remains in their cache
  184. 193. And is re-used when they revisit that site
  185. 194. From inside the secure office network (or wherever) </li></ul>
  186. 195. Don't think it's a problem?
  187. 196. Making it happen <ul><li>Cache-control: max-age=99999999, public -or- Expires: Fri, 13 May 2011 13:13:13 GMT
  188. 197. So we hijack a common JS file
  189. 198. Spike it with malicious code
  190. 199. Set it to cache
  191. 200. Now when the user goes back to work and goes to twitter again... </li></ul>
  192. 201. Watch the spikes <ul><li>User now has a spiked, cached javascript
  193. 202. Browser will keep this and re-use it every time until it expires
  194. 203. Iframes? Kaminsky socket/sucket? Load new browser exploits?
  195. 204. But a user would never go to Twitter at work, right? </li></ul>
  196. 205. Poisoning the well <ul><li>How many sites use Urchin.js...
  197. 206. Hosted off the same URL at google?
  198. 207. What happens when we poison the url?
  199. 208. We get script execution on every site using it </li></ul>
  200. 209. Call home to Mom <ul><li>Cache modified JS that calls home every time the page is visited
  201. 210. Maybe no good attacks in the browser this week?
  202. 211. Wait for a browser 0day then flip the switch to include malware
  203. 212. Every system that has the cached call-home is attacked as soon as the users visit the poisoned site </li></ul>
  204. 213. There are no innocents <ul><li>No website is “innocent”
  205. 214. Websites that don't ask for logins are just as capable of feeding browser exploits
  206. 215. Any website can be poisoned with browser-owning code </li></ul>
  207. 216. Never underestimate fools <ul><li>But won't SSL solve it?
  208. 217. Not really, users still have to be smart enough to not accept a bad cert
  209. 218. And users would never do something insecure, right?
  210. 219. OBVIOUSLY that pop star wants me to see her naked! </li></ul>
  211. 225. Self-made cert <ul><li>Self-signed certificates are “obvious”
  212. 226. But we're technical people
  213. 227. “ Signed by VeriSign” vs “Signed by Verisign” “Verisign” vs “Verisign”?
  214. 228. Assuming a user even looks and doesn't just click “OK”
  215. 229. Users just want the web
  216. 230. “ Click OK until porn” </li></ul>
  217. 231. Well aren't you clever... <ul><li>I'm smart!
  218. 232. I use a VPN! -or-
  219. 233. I force my users to use a VPN via user management!
  220. 234. This won't work against me! </li></ul>
  221. 235. Yuh huh but... <ul><li>You're right, it wouldn't... …
  222. 236. Except your browser has no concept of security domains
  223. 237. What was cached in an insecure domain will remain for a secure domain </li></ul>
  224. 238. “Click OK to agree...” <ul><li>Many hotspots have a landing page to agree to EULA or sign in
  225. 239. Many first-stage landers are not encrypted
  226. 240. Unencrypted page on open network? Perfect target </li></ul>
  227. 241. Magic (h)8 ball <ul><li>If attacker controls your pre-vpn landing page...
  228. 242. Then the attacker can control your browser...
  229. 243. Iframes? Pop-under windows? Ajax queries dumped to nowhere? </li></ul>
  230. 244. Top 10 countdown <ul><li>All the attacker needs to do is inject code to go to the top N pages the victim may be likely to visit
  231. 245. Request page in the background
  232. 246. Cache spiked page (which the victim never saw) </li></ul>
  233. 247. Smart JS <ul><li>Attacker landing page can request content multiple times
  234. 248. Compare content with signature for attack
  235. 249. Request again if attack didn't land
  236. 250. Now we own arbitry sites in cache PRE-VPN </li></ul>
  237. 251. Frequent Landings <ul><li>Take it one step further: VPN allows access to internal pages, right?
  238. 252. So if the attacker controls L2... </li></ul>
  239. 253. D umb N etwork S tuff <ul><li>If we own L2, can we attack other protocols?
  240. 254. Sure can!
  241. 255. Race the DNS server!
  242. 256. Wait for a DNS query, then...
  243. 257. Set a QR flag on the request and supply our own response </li></ul>
  244. 258. DNS-pwn in MSF <ul><li>Same model as Airpwn
  245. 259. YAML config to match multiple queries with different responses
  246. 260. Races DNS server to give user a “custom” IP </li></ul>
  247. 261. Your intranet is showing <ul><li>So if we control the browser
  248. 262. We control DNS resolution
  249. 263. We can re-try as quickly as we want thanks to a JS script that watches for success...
  250. 264. What stops us from caching http://intranet/ </li></ul>
  251. 265. (hint: Nothing) <ul><li>Nothing!
  252. 266. How about a shim that ships your internal pages off to a remote server once you're on VPN?
  253. 267. Or just rewrites all your form DOMs to proxy out? </li></ul>
  254. 268. Browsers cache other stuff too! <ul><li>Browsers are great!
  255. 269. Speed of user experience is the biggest concern...
  256. 270. So lets cache DNS in the browser, too!
  257. 271. So this means...? </li></ul>
  258. 272. Trust me, it's over here <ul><li>Pre-VPN browser DNS poisoning
  259. 273. Post-VPN site control thanks to guessed internal DNS names being cached as external servers </li></ul>
  260. 274. “Mobile Convergence”
  261. 275. “Smart” phones are dumb? <ul><li>So-called “smart” phones are really general-purpose computers now
  262. 276. Complex browsers
  263. 277. Lower bandwidth networks
  264. 278. Yup, very happy to cache data </li></ul>
  265. 279. Not talking to you <ul><li>Of course, all the smartphones are on cell networks, right?
  266. 280. I'll just use 3G!
  267. 281. You can't see me there!
  268. 282. True... </li></ul>
  269. 287. Used to fail <ul><li>Smartphone users are used to going to wifi
  270. 288. Some prefer it – power / speed / data limits
  271. 289. Besides, we could “help” them along... </li></ul>
  272. 291. No, you shouldn't <ul><li>You absolutely should NOT go to import sites
  273. 292. You should NOT buy illegal cell phone jammers to force victims to use wifi
  274. 293. And of course someone trying to own your company wouldn't do something illegal , right? </li></ul>
  275. 294. Where we go from here <ul><li>Future plans:
  276. 295. Better MSF integration with other L2 attacks
  277. 296. Dynamic content generation based on target
  278. 297. Integration with browser autopwn </li></ul>
  279. 298. In summary... <ul><li>We've more or less figured out how to defend access points
  280. 299. It's much harder to defend clients
  281. 300. Especially when they go off into the world onto insecure APs </li></ul>
  282. 301. In summary... <ul><li>Using an open network?
  283. 302. Sites you think you trust, you can't
  284. 303. Spiked attacks can stay resident in the browser
  285. 304. Your users might be bringing something back with them </li></ul>
  286. 305. In summary... <ul><li>This is bad even for smart users
  287. 306. Normal users don't stand a chance
  288. 307. You may already be screwed
  289. 308. I warned you this would be depressing... </li></ul>
  290. 309. Trying to fix it <ul><li>Use a VPN – at least it's a start despite the problems
  291. 310. Easy for US
  292. 311. Hard for most users
  293. 312. Hard to enforce: Users don't like barriers between them and internet </li></ul>
  294. 313. Other options <ul><li>SSH SOCKS tunneling (basically just a VPN)
  295. 314. Mandate updates (easier said than enforced)
  296. 315. Forbid users from taking laptops onto open networks (policy, UAC, don't give out laptops?) </li></ul>
  297. 316. Tragedy of trust <ul><li>Would be nice to say “move open networks to WPA”
  298. 317. WPA-PSK? Better but not a solution.
  299. 318. WPA-EAP? Better still, even with the same user/password you get per-user keying </li></ul>
  300. 319. Tragedy of trust <ul><li>But WPA-EAP requires SSL
  301. 320. If cert is signed by a common CA, easy to get another from the same CA
  302. 321. If cert is signed by self-sign CA user has to accept
  303. 322. Up to user to determine valididy
  304. 323. Not what users are good at </li></ul>
  305. 324. Stuck in the rut <ul><li>Hard to deploy secure public networks
  306. 325. Some vendors try to solve it with custom clients
  307. 326. Ties into specific OS then
  308. 327. Running foreign binaries
  309. 328. No really good solution yet </li></ul>
  310. 329. Protecting yourself <ul><li>Manually enforce security domains
  311. 330. Use different browsers for login and normal use
  312. 331. Manually clear cache
  313. 332. Never keep windows open between security domains
  314. 333. Still scary, forget once and you're screwed </li></ul>
  315. 334. Thanks to.. <ul><li>Rsnake
  316. 335. HDM
  317. 336. Toast
  318. 337. Renderman
  319. 338. Jesse Burns
  320. 339. Everyone else who has listened to me rant about this </li></ul>
  321. 340. Q & A <ul><li>Lorcon @ 802.11ninja.net
  322. 341. Kismet @ www.kismetwireless.net
  323. 342. MSF @ metasploit.com
  324. 343. Me @ dragorn@kismetwireless.net </li></ul>

×