Reticle: Dropping an Intelligent F-BOMB

This was my presentation at BSides Las Vegas 2012. For more information (including the video), check out http://blog.ussjoin.com/2012/07/reticle.html .

Abstract:

F-BOMB is a disposable computing project, and Reticle is its software brain: a distributed, leaderless system for transferring data and commands to and from the tiny, distributed, dirt-cheap little boxes. Together, these two systems form a botnet-styled sensor network that can be deployed the same way as a smoke grenade by a field agent, but with intelligent encryption, plausible deniability, and a peer-to-peer command network to ensure that an enemy can't compromise your goals-- whether you're providing Internet access to an Occupy group, or playing distributed hide and seek for cell phones. We discuss the design and implementation of Reticle, which was intended to take some of the networking ideas from modern botnets and apply them in a more useful context. Reticle was created with support from DARPA Cyber Fast Track, and the code, utilities, and documentation created under that project will be released with the talk.

Transcript

1. RETICLE: DROPPING AN INTELLIGENT F-BOMB Brendan O’Connor, CTO/DSS Malice Afterthought, Inc. Think again. a decentralized botnet for disposable computing
2. BRENDAN O'CONNOR • CTO/DSS, Malice Afterthought, Inc • Rising 2L at the University of Wisconsin School of Law - IANAL,Y • I've done DARPA stuff, security research, and even Network Warfare teaching for DoD (want to hire me? I'm always looking, so ping me!) • BTW, No One Authorized Me To Say ANYTHING! I speak for nobody.
3. DARPA CYBER FAST TRACK
4. ROADMAP • Scenarios (The Problem) • F-BOMB (The Hardware) • Reticle (The Software) • Missions (What It Does) • Next
5. SCENARIO 1: ENVIRONMENTAL RESEARCH
6. SCENARIO 2: BAD MEN WITH GUNS
7. SCENARIO 3: OCCUPY
8. WHAT WE WANT • A system for cheap, disposable computers • Deployable by untrained personnel • Reconfigurable post-deployment • Capable of independent or coordinated action • With sufficient processing power to take on high-level tasks • @Dakami - “Ever deployed hardware? It’s not fun.” I disagree!
9. ROADMAP • Scenarios (The Problem) • F-BOMB (The Hardware) • Reticle (The Software) • Missions (What It Does) • Next
10. FALLING/BALLISTICALLY-LAUNCHED OBJECT THAT MAKES BACKDOORS • Design Goals • Cheap -- < $75, < $50 if possible • Reconfigurable Hardware for Different Sensors • Ultimately, this will require USB for cheapest sensors • Light enough to be flown on a UAV, or thrown, hard • Durable enough to land poorly (we’ll come back to this) • Ubiquitous enough to be deniable-- no bespoke PCBs
11. WHY NOT THE PWNIE PLUG?
12. WHY NOT THE MINIPWNER?
13. WHY NOT THE WASP?
14. F-BOMB, VERSION 1 PogoPlug (v2/v3) Core Flash Drive 2x RTL8188 PogoPlug POGO-B01 Mainboard
15. BRIGHT PINK INFILTRATION
16. RECONFIGURABLE
18. EXCESSIVELY REAL-WORLD TESTING
19. WHOOPS
20. ROADMAP • Scenarios (The Problem) • F-BOMB (The Hardware) • Reticle (The Software) • Missions (What It Does) • Next
21. RETICLE
22. RETICLE DESIGN GOALS • Minimum Viable Hardware - exploit local WiFi for comms • Deniable Deployment • Encrypted storage, with no local key storage! • Encrypted communications • No Central C&C Server - fully peer-to-peer, no SPOF • Resistance to Central Compromise / Node Compromise • As easy to deploy as a life jacket, but still with crypto.
23. NOT DESIGN GOALS • Mesh Network • Really great research, but hard for untrained users in the field to deploy in an efficient way • Instead we’ll use “the Cloud” as our mesh! • Synchronous Communication / Simultaneous Command
24. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems
25. SOLUTION: A CLONE ARMY
26. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use?
27. GRENADE-STYLE KEY MANAGEMENT
28. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Endpoints
29. SOLUTION: TOR
30. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Tor • Easy Local Storage
31. SOLUTION: COUCHDB
32. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Tor • Easy Local Storage Couch • Peer-to-Peer Replication
33. SOLUTION: COUCHDB
34. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Tor • Easy Local Storage Couch • Peer-to-Peer Replication Couch • Encrypted, Revokable Communications
35. SOLUTION: COUCHDB?
36. STEP 3.5: FILE A BUG REPORT
37. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Tor • Easy Local Storage Couch • Peer-to-Peer Replication Couch • Encrypted, Revokable Communications
38. SOLUTION: NGINX
39. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Tor • Easy Local Storage Couch • Peer-to-Peer Replication Couch • Encrypted, Revokable Communications Nginx • Initial introductions to the peer-to-peer network
40. EXPLANATION: I WISH I HAD FRIENDS
41. STEP 6.1: REMEMBER USENET?
42. STEP 6.2: THE SASSAMAN MEMORIAL HACK
43. PROBLEMS TO SOLVE • Enough hardware to test performance on embedded systems DARPA • How do we have encrypted storage without storing the key on-disk but still easy to use? USB Drive • Obfuscating Traffic Tor • Easy Local Storage Couch • Peer-to-Peer Replication Couch • Encrypted, Revokable Communications Nginx • Introductions to the peer-to- peer network Usenet
44. PROFIT!
45. ROADMAP • Scenarios (The Problem) • F-BOMB (The Hardware) • Reticle (The Software) • Missions (What It Does) • Next
46. TESTING MISSIONS
47. MISSIONS SO FAR • Blinkenlights • Stalkr • OKCreepy • Private Web Browsing (Auto-Tor) • Note that we get wireless bridging / area extension for free!
48. OTHER EASY MISSIONS • P25 listeners (SDRs are now $25!) • A shout-out to Matt Blaze / Travis Goodspeed • “Why (Special Agent) Johnny (Still) Can’t Encrypt” • ...a thousand other things (and reconfigurable on the fly) • Also missions aren’t exclusive, though Reticle doesn’t attempt to negotiate sharing of devices; this isn’t designed as a public resource network
49. ROADMAP • Scenarios (The Problem) • F-BOMB (The Hardware) • Reticle (The Software) • Missions (What It Does) • Next -- and how you can help!
50. NEXT STEPS FOR RETICLE • Opportunistic Replication • Change the scan+connect script to run continuously, and replicate whenever we find a connection • MIT did this, but won’t release the source code :-( • Data Visualization for hordes of data • New hardware (F-BOMB v2) - mmm, Raspberry Pi!
51. NEW PROJECT: SPOTLIGHT
52. SPOTLIGHT • Hide and Seek • No trained “seekers” • We’ll use bicycle couriers and bored students • 20 Reticle Nodes • 12 Hours • 10 Targets (5 mobile, 5 static)
53. SPOTLIGHT Anyone want to come play with us? We’d love to partner. brendan@maliceafterthought.com