Your SlideShare is downloading. ×
Wifi Security, or Descending into Depression and Drink
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Wifi Security, or Descending into Depression and Drink

1,936

Published on

Published in: Education, Technology
1 Comment
1 Like
Statistics
Notes
  • 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
No Downloads
Views
Total Views
1,936
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Wifi Security -or- Descending Into Depression and Drink Mike Kershaw / Dragorn [email_address]
  • 2.  
  • 3. 802.11
    • 2.4 and 5.8 GHz
    • 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
  • 7. Packing your bags
    • Unlike frequency-hopping protocols, trivial to capture 802.11
    • 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
  • 11. I come not to bury 802.11...
    • We've got a pretty good idea about 802.11 security by now
    • 12. By “we” I mean “security professionals”
    • 13. But even “the great unwashed” are clueing in, kind of. Encryption on home nets is up
  • 14. Secure configurations
    • WiFi is secure in proper deployments
    • 15. WPA-Enterprise
    • 16. Per-user authentication
    • 17. Per-user keying
    • 18. Mutual auth via certificates
  • 19. Strong encryption
    • We've got a pretty solid crypto system
    • 20. AES used in WPA-CCMP as yet unbroken
    • 21. TKIP showing flaws, but is already past sell-by date, move to CCMP
  • 22. “Done Properly”
    • WPA-Enterprise secure “done correctly”
    • 23. Opportunities for failure exist if users don't validate certs (or are allowed to say 'ok')
    • 24. TKIP will eventually fall
  • 25. 802.11 AP Defense
    • We've been doing this for a long time now
    • 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
  • 29. Client Protection
    • Inter-client traffic can be blocked at the AP
    • 30. Defending clients on a strong network is easy since the AP controls crypto
    • 31. Defending clients on open AP is very hard
  • 32. Denial of Service Attacks
    • Management frames unprotected
    • 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.
  • 36. Punching 802.11 in the gut
    • Absurdly easy
    • 37. Management frames are totally unprotected
    • 38. Open networks are un-authenticateable
    • 39. It's shared media
  • 40. Strangers with candy
    • Avoiding hostile networks requires smart users
    • 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
  • 44.  
  • 45. Going viral
    • Users like free wi-fi
    • 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
  • 50. Sore throats
    • Of course, this junk ad-hoc network doesn't go anywhere
    • 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?
  • 55. Being too trusting
    • Clients are really trusting
    • 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
  • 59. 802.11 Roaming
    • Multiple AP with same SSID
    • 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
  • 64.  
  • 65. The packets must flow
    • So if an attacker has a stronger radio than the AP...
    • 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
  • 69. Stuck in the middle with...
    • Dual-interface attacker
    • 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...
  • 72. More Man-in-the-middle
    • Many sites encrypt login, but not session
    • 73. Session cookies, data, etc vuln
    • 74. “ The Middler”, SSLSniff, Cookie Monster
    • 75. Hijack sessions via MITM
  • 76. This bores me
    • All of these attacks are really pretty boring
    • 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.
  • 80. So wait...
    • Didn't we say 802.11 is shared media !?
    • 81. We just found the best time machine ever !
  • 82.  
  • 83. And not some hippy do-gooder time machine, either
  • 84.  
  • 85. But one where we get to bring back weapons from the future
  • 86.  
  • 87. The bad old days
    • Hair metal, grunge, ripped jeans
    • 88. Unswitched shared media Ethernet...
    • 89. Sniffing the entire segment …
    • 90. TCP session hijacking...
  • 91. That's too easy
    • It'd never be that easy, right?
    • 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 ?
  • 95.  
  • 96. Mmm, latte
  • 102. Making a mess
    • Management frames have no protection
    • 103. Open networks have no client protection
    • 104. Nothing stops us from spoofing the AP and talking directly to a client!
  • 105. No protection
    • AP may try to filter inter-client communication by blocking packets when they hit the AP
    • 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
  • 110. Making it easy: LORCON
    • Writing the same injection code for every app sucks
    • 111. Writing custom code for each driver sucks
    • 112. Writing apps for each OS sucks
    • 113. Hopefully LORCON doesn't suck
  • 114. LORCON2
    • Unfortunately... the LORCON1 API... kind of sucked
    • 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
  • 120. Super simple
    • Automatically determines the driver
    • 121. Automatically configures virtual network interfaces and sets up modes for injection
    • 122. Send arbitrary bytes -or- use packet assembly API
  • 123. The inspiration
    • Wifi session hijacking
    • 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!
  • 128.  
  • 129. Rerouting streams
    • Typical layer2 attack
    • 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
  • 133. Anatomy of a session
    • Handshake
    • 134. Client -> Server “GET /foo.html HTTP/1.0” Seq 123 ack 10
    • 135. Server ← Client “HTTP headers, content” Seq 10 ack 189
  • 136. So lets add this to MSF
    • Lorcon Ruby wrapper
    • 137. Racket packet assembly (high speed Ruby packet assembly)
    • 138. Ruby PCAP
    • 139. And a little TLC
  • 140. Anatomy of an Evil session
    • Handshake
    • 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
  • 148. Fine-tuning
    • Match & replace in regex
    • 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)
  • 151. Autogen
    • Airpwn-MSF automatically generates HTTP headers as needed
    • 152. Complete attacker control of page content including headers , too
  • 153. Ill-gotten profit
    • What does that get us?
    • 154. HTTP content replacement
  • 155. Or in other words...
    • Control over the page DOM
    • 156. Control over forms
    • 157. Control over the browser in general
    • 158. Access to anything in the security context of the compromised page
  • 159. Obviously scripted
    • So we can replace content...
    • 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
  • 164. JS Fragments
    • Especially attractive
    • 165. Totally invisible to the user
    • 166. Multiple requests = Multiple opportunities to land attack
    • 167. Run in same privilege domain as web page
  • 168. I'm in your browser
    • Rewriting your DOM
    • 169. DOM = Document Object Model
    • 170. Programmatic manipulation of page content
    • 171. Once in the DOM we can do ANYTHING
  • 172.  
  • 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;; }}
  • 174. DOM is tasty
    • What else can we do?
    • 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;); }
  • 179. This really matters
  • 182. Persistence pays off
    • Who has read rsnake's VPN paper?
    • 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
  • 186. Fast cache
    • Short version of the VPN paper:
    • 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
  • 191. Fast cache
    • Client is fed a spiked JS file with cache set to 10 years
    • 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?
  • 196. Making it happen
    • Cache-control: max-age=99999999, public -or- Expires: Fri, 13 May 2011 13:13:13 GMT
    • 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...
  • 201. Watch the spikes
    • User now has a spiked, cached javascript
    • 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?
  • 205. Poisoning the well
    • How many sites use Urchin.js...
    • 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
  • 209. Call home to Mom
    • Cache modified JS that calls home every time the page is visited
    • 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
  • 213. There are no innocents
    • No website is “innocent”
    • 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
  • 216. Never underestimate fools
    • But won't SSL solve it?
    • 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!
  • 220.  
  • 221.  
  • 222.  
  • 223.  
  • 224.  
  • 225. Self-made cert
    • Self-signed certificates are “obvious”
    • 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”
  • 231. Well aren't you clever...
    • I'm smart!
    • 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!
  • 235. Yuh huh but...
    • You're right, it wouldn't... …
    • 236. Except your browser has no concept of security domains
    • 237. What was cached in an insecure domain will remain for a secure domain
  • 238. “Click OK to agree...”
    • Many hotspots have a landing page to agree to EULA or sign in
    • 239. Many first-stage landers are not encrypted
    • 240. Unencrypted page on open network? Perfect target
  • 241. Magic (h)8 ball
    • If attacker controls your pre-vpn landing page...
    • 242. Then the attacker can control your browser...
    • 243. Iframes? Pop-under windows? Ajax queries dumped to nowhere?
  • 244. Top 10 countdown
    • All the attacker needs to do is inject code to go to the top N pages the victim may be likely to visit
    • 245. Request page in the background
    • 246. Cache spiked page (which the victim never saw)
  • 247. Smart JS
    • Attacker landing page can request content multiple times
    • 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
  • 251. Frequent Landings
    • Take it one step further: VPN allows access to internal pages, right?
    • 252. So if the attacker controls L2...
  • 253. D umb N etwork S tuff
    • If we own L2, can we attack other protocols?
    • 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
  • 258. DNS-pwn in MSF
    • Same model as Airpwn
    • 259. YAML config to match multiple queries with different responses
    • 260. Races DNS server to give user a “custom” IP
  • 261. Your intranet is showing
    • So if we control the browser
    • 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/
  • 265. (hint: Nothing)
    • Nothing!
    • 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?
  • 268. Browsers cache other stuff too!
    • Browsers are great!
    • 269. Speed of user experience is the biggest concern...
    • 270. So lets cache DNS in the browser, too!
    • 271. So this means...?
  • 272. Trust me, it's over here
    • Pre-VPN browser DNS poisoning
    • 273. Post-VPN site control thanks to guessed internal DNS names being cached as external servers
  • 274. “Mobile Convergence”
  • 275. “Smart” phones are dumb?
    • So-called “smart” phones are really general-purpose computers now
    • 276. Complex browsers
    • 277. Lower bandwidth networks
    • 278. Yup, very happy to cache data
  • 279. Not talking to you
    • Of course, all the smartphones are on cell networks, right?
    • 280. I'll just use 3G!
    • 281. You can't see me there!
    • 282. True...
  • 283.  
  • 284.  
  • 285.  
  • 286.  
  • 287. Used to fail
    • Smartphone users are used to going to wifi
    • 288. Some prefer it – power / speed / data limits
    • 289. Besides, we could “help” them along...
  • 290.  
  • 291. No, you shouldn't
    • You absolutely should NOT go to import sites
    • 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?
  • 294. Where we go from here
    • Future plans:
    • 295. Better MSF integration with other L2 attacks
    • 296. Dynamic content generation based on target
    • 297. Integration with browser autopwn
  • 298. In summary...
    • We've more or less figured out how to defend access points
    • 299. It's much harder to defend clients
    • 300. Especially when they go off into the world onto insecure APs
  • 301. In summary...
    • Using an open network?
    • 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
  • 305. In summary...
    • This is bad even for smart users
    • 306. Normal users don't stand a chance
    • 307. You may already be screwed
    • 308. I warned you this would be depressing...
  • 309. Trying to fix it
    • Use a VPN – at least it's a start despite the problems
    • 310. Easy for US
    • 311. Hard for most users
    • 312. Hard to enforce: Users don't like barriers between them and internet
  • 313. Other options
    • SSH SOCKS tunneling (basically just a VPN)
    • 314. Mandate updates (easier said than enforced)
    • 315. Forbid users from taking laptops onto open networks (policy, UAC, don't give out laptops?)
  • 316. Tragedy of trust
    • Would be nice to say “move open networks to WPA”
    • 317. WPA-PSK? Better but not a solution.
    • 318. WPA-EAP? Better still, even with the same user/password you get per-user keying
  • 319. Tragedy of trust
    • But WPA-EAP requires SSL
    • 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
  • 324. Stuck in the rut
    • Hard to deploy secure public networks
    • 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
  • 329. Protecting yourself
    • Manually enforce security domains
    • 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
  • 334. Thanks to..
  • 340. Q & A
    • Lorcon @ 802.11ninja.net
    • 341. Kismet @ www.kismetwireless.net
    • 342. MSF @ metasploit.com
    • 343. Me @ dragorn@kismetwireless.net

×